External attack-surface inventory

This detector answers a single question a security team needs before any review: what of this org is reachable from outside? Vulkro walks the metadata that defines external exposure (Sites, guest-user configuration, sharing and public groups, OAuth endpoints, annotated web services, and public Visualforce) and produces an inventory of every externally reachable surface, with a rollup that summarizes the total.

An attack-surface inventory is not the same as a vulnerability scan. A public surface is not automatically a bug. The point is to make the externally reachable footprint explicit, so a reviewer can confirm each exposed surface is intentional and adequately protected rather than an accident nobody remembers shipping.

SF-ATTACK-SURFACE-000: rollup

The -000 finding is the inventory rollup. It aggregates every contributing surface below into one summary so a reviewer can size the external footprint at a glance, then drill into the specific findings.

How to read it: treat the rollup as the section header for the external exposure conversation, then walk the -001 through -006 findings to confirm each surface is intended and guarded.

SF-ATTACK-SURFACE-001: public Sites

Triggers when a Salesforce Site (Experience Cloud or Site.com) is configured for public, unauthenticated access.

Why it matters: a public Site is internet-reachable with no login. Every page, controller, and resource it exposes is part of the org's public attack surface, and any over-permissioned backend behind it is exposed to anonymous callers.

How to fix: confirm the Site is meant to be public. If so, review the guest-user profile and every controller the Site reaches. If not, restrict the Site to authenticated access.

SF-ATTACK-SURFACE-002: guest-user access

Triggers when the guest user associated with a public Site or community holds object or field access beyond the minimum needed to render the public experience.

Why it matters: the guest user is the identity an anonymous visitor acts as. Any object the guest user can read or write is readable or writable by the entire internet through the public Site.

How to fix: strip the guest user down to the minimum object and field access the public pages require, and prefer explicit sharing over broad profile grants.

SF-ATTACK-SURFACE-003: broad sharing or public groups

Triggers when sharing rules or public group membership grant broad access in a way that widens what an external or low-privilege principal can reach.

Why it matters: a broad sharing rule or an over-inclusive public group can silently extend record visibility to the guest user or to a wide internal audience, expanding the effective external surface beyond what the Site configuration alone suggests.

How to fix: tighten the sharing rule criteria and audit public group membership so access maps to a clear, intended audience.

SF-ATTACK-SURFACE-004: OAuth endpoints

Triggers when OAuth endpoints are exposed through Connected Apps that accept external authorization.

Why it matters: an OAuth endpoint is an external authentication entry point. It belongs in the inventory because the scopes and principals behind it determine how much an authorized third party can reach.

How to fix: cross-check each OAuth endpoint against its Connected App scope and approval policy, and confirm every exposed endpoint corresponds to a known, approved integration.

SF-ATTACK-SURFACE-005: exposed REST and HTTP web services

Triggers when Apex web services are exposed through @RestResource, @HttpGet, @HttpPost, or sibling annotations that publish a callable endpoint.

Why it matters: an annotated web service is a callable endpoint. If it performs reads or state changes without enforcing CRUD, field-level security, and sharing in the method body, an external caller reaches data or actions through it directly.

How to fix: confirm each exposed service is intended to be external, and enforce authorization inside the method (CRUD and field-level checks, sharing, and an authentication gate) rather than relying on the endpoint being obscure.

SF-ATTACK-SURFACE-006: public Visualforce

Triggers when a Visualforce page is reachable on a public Site or is otherwise exposed to unauthenticated access.

Why it matters: a public Visualforce page exposes its controller logic to anonymous callers and is a common reflected-XSS and parameter-tampering surface when the controller reads request parameters without escaping.

How to fix: confirm the page is meant to be public, review its controller for unescaped request-parameter handling, and remove it from public exposure if it was never intended to be anonymous.