Public credentials
Classify keys and token-like values visible in public code, source maps, page-load metadata, and browser storage. Provider-aware rules separate publishable identifiers from potentially privileged credentials.
security coverage
Start with public evidence. Go deeper with permission.
SafeForProd has three levels of coverage. Each one explains what it can establish, what remains outside scope, and which next step can resolve the uncertainty.
01 · free passive scan
What a normal visitor can access
Submit a live URL without creating an account. We inspect only the submitted page, its referenced public files, response headers, and requests that page initiates during normal loading.
Live URL · No repository access · Public retrieval only
Source maps and debug artifacts
Detect referenced source maps, unminified production bundles, verbose errors, development builds, comments, and public configuration.
Browser security controls
Review CSP, HSTS, clickjacking protection, content-type controls, referrer policy, permissions policy, cookie attributes, and CORS headers returned during the submitted page load.
Public API surface
Map API routes, GraphQL endpoints, Supabase projects, third-party services, and internal hostnames referenced by public bundles or requests the submitted page initiates itself.
Session and storage hygiene
Identify sensitive-looking values, authentication state, personal-data patterns, and client-only access decisions visible in storage, cookies, and public code. No discovered value is used.
Stack and deployment signals
Identify frameworks, platforms, staging artifacts, version disclosure, development services, and administrative tooling exposed to visitors.
02 · authorized source scan
What source access and approved tests can verify
This planned product will require an account, a ZIP or selected read-only GitHub repository, explicit authorization, and verified domain control before any active runtime test begins.
Planned · Account required · ZIP or read-only GitHub · Verified domain
Authentication coverage
Compare source-defined routes with the deployed application and verify that selected sensitive endpoints reject unauthenticated requests.
Authorization and tenant isolation
Review ownership checks, roles, IDOR patterns, and cross-tenant data paths in source and approved test accounts.
Supabase RLS and data boundaries
Inspect policies and grants for relevant tables, then validate approved access paths without retaining customer data.
Secrets and configuration
Inspect source files, environment templates, repository history, framework configuration, and deployment settings for unsafe defaults or server-only credentials.
Routes and deployed behavior
Compare source-discovered endpoints with the live application to find missing controls, forgotten routes, and unexpected differences.
Approved endpoint validation
Test selected sensitive routes, GraphQL behavior, known paths, and basic rate limiting under strict request budgets and recorded scope.
Focused static analysis
Run high-signal security rules chosen for the application stack, while separating exploitable findings from routine maintenance.
Dependencies and supply chain
Review dependency risk and exposed package behavior. Outdated software stays informational unless it creates a demonstrated security impact.
03 · human security review
What requires experienced judgment
A senior security engineer reviews the agreed high-risk paths, validates findings, and signs the scoped report.
Business logic
Review payments, approvals, invitations, account recovery, role changes, exports, and other workflows that can be technically valid but logically unsafe.
Architecture and trust boundaries
Trace where authorization decisions happen, how data moves, and which users, services, and components are trusted at each boundary.
Sensitive data flows
Follow personal, financial, authentication, and tenant data through the relevant code paths and integrations.
Finding validation
Confirm real vulnerabilities, remove false positives, and separate urgent risks from normal hardening recommendations.
Prioritized remediation
Turn findings into a practical fix order based on exploitability, affected users, business impact, and engineering effort.
Signed review
A senior security engineer specializing in cloud and application security reviews the agreed code paths and signs the scoped report.
Human review is scoped to the agreed code and workflows. It does not imply that every line was reviewed unless the scope explicitly says so.
how results are reported
Evidence state is separate from severity
A potential issue can have serious impact and still need verification. SafeForProd never presents uncertainty as a confirmed vulnerability.
Confirmed
Reproducible evidence within the scan scope establishes that the condition exists.
Needs verification
A credible signal exists, but the current access or scope cannot confirm the security outcome.
Informational
Useful context or hardening guidance without a demonstrated vulnerability.
Not tested
The control or surface was outside scope or was not exercised. This is not a passing result.
every finding includes
Result state Evidence Confidence Severity Business impact Remediation Scope boundary Next validation step
start outside-in
See what your live app already exposes
Start with the free scan. Add source access and human review only when you need deeper validation.
Scan my app free