Sample report · Free passive scan

A public-surface report shows what the evidence proves — and what it does not.

This is a hypothetical example built to demonstrate the Free passive scan report structure. It is not a customer result, scan statistic, or claim about a real application. For the expert deliverable, see the sample Human security review.

Hypothetical free scan · public-surface scope

example.app

Submitted URL: https://example.app/
Access: Public page only
Account: None
Active tests: None

1 Confirmed

1 Needs verification

1 Informational

1 Not tested

Confirmed F-001

Content-Security-Policy header is missing

Severity

Medium

Evidence: The HTML response for https://example.app/ did not include a Content-Security-Policy or Content-Security-Policy-Report-Only header.
Impact: CSP can limit the impact of some script-injection paths. Its absence is a hardening gap, not proof that script injection is possible.
Remediation: Define a policy from the resources the app actually needs. Start in report-only mode, review violations, then enforce the smallest workable allowlist.
Scope and limitation: Confirmed from the submitted page response. Other routes were not requested.

Retest: Not retested

Needs verification F-002

High-risk credential pattern appears in public JavaScript

Severity

High if privileged

Evidence: A referenced bundle contained a provider-specific value that matches the format of a privileged server credential. The value is redacted in the report.
Impact: If the value is current and privileged, a visitor could copy it. The free scan does not use the value, call the provider, or infer access from format alone.
Remediation: Verify the credential role in the provider dashboard. If it is privileged, revoke and rotate it, move the replacement server-side, and rebuild the public assets.
Scope and limitation: Pattern and public location observed. Role, validity, permissions, and reachable data were not tested.

Retest: Requires owner verification

Informational F-003

Supabase project URL and publishable client key are visible

Severity

None assigned

Evidence: The client initialization includes the project URL and an anon/publishable key, as expected for browser-side Supabase clients.
Impact: Visibility alone is not a secret leak. The security boundary is enforced by Row Level Security, grants, and server-side handling of privileged keys.
Remediation: Do not rotate a publishable key merely because it is public. Review RLS and grants through the planned Authorized source scan, or an equivalent owner-run review, if you need assurance about data access.
Scope and limitation: Key class identified from public configuration. No table, policy, or data request was tested.

Retest: No public-surface fix required

Not tested C-001

Row Level Security enforcement

Severity

Not rated

Evidence: No database table was queried and no authenticated role was exercised.
Impact: The public-surface report cannot conclude that RLS is correct, missing, or bypassable.
Remediation: Review policies, grants, ownership checks, and approved role behavior through the planned Authorized source scan, an equivalent owner-run review, or a Human security review.
Scope and limitation: Outside the free scan’s public-surface scope.

Retest: Needs authorized scope

This is the evidence standard, at every level.

The free scan applies this contract to browser-visible evidence. The sample Human security review shows the same contract applied to source, authorized testing, and business logic.

Scan my app free Request a security review