Sample security assessment report

A sensitive admin-style route was publicly reachable and exposed enough structure to confirm that the application has privileged management surfaces on the public internet.

If authentication or authorization controls around this path are weak anywhere else in the stack, this becomes a direct path to user records, configuration, or internal actions.

The scanner identified a live `/admin` route with a recognizable login shell and response signature that confirms an admin surface exists publicly.

• Restrict the route behind IP allowlists, private networking, or zero-trust access.
• Require strong server-side authorization for every admin action.
• Rate-limit and monitor all admin authentication attempts.

if not request.user.is_admin:
    raise HTTPException(status_code=403, detail='Admin access required')

A production JavaScript source map was publicly accessible, making the application easier to reverse-engineer.

Source maps can reveal internal file structure, component names, API paths, and implementation details that reduce the effort required for targeted attacks.

A `.map` asset returned a successful response and exposed original source references from the production bundle.

• Disable production source maps in your frontend build.
• Invalidate any already-cached source map URLs from the CDN.
• Re-scan after deployment to confirm the files are no longer reachable.

productionBrowserSourceMaps: false

The main application response did not set a Content-Security-Policy header.

Without CSP, any client-side injection issue becomes much easier to weaponize because the browser has fewer limits on script execution sources.

The scanner captured the main page response headers and confirmed that CSP was missing from the production response.

• Define a strict Content-Security-Policy for scripts, styles, images, and connections.
• Start with report-only mode if needed, then move to enforcement.

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';

An API response accepted a broader origin pattern than expected for a user-data endpoint.

Loose CORS policies increase the chance that sensitive API responses can be requested from unintended browser origins if other auth controls are weak.

The endpoint responded with an `Access-Control-Allow-Origin` value that was broader than the expected production frontend origin.

• Allow only the exact production frontend origin.
• Avoid wildcard or environment-wide defaults for authenticated endpoints.

allow_origins=['https://app.yourdomain.com']

The session cookie did not use the strongest cross-site restriction available for this flow.

Weak cookie attributes can increase exposure to cross-site request scenarios and session abuse, especially in mixed-origin deployments.

The `Set-Cookie` header was observed without the expected strict SameSite setting for a login/session cookie.

• Use `Secure`, `HttpOnly`, and the strongest valid `SameSite` policy for your product flow.
• Review whether any third-party redirect flow truly requires a weaker cookie policy.

response.set_cookie('session', value=token, httponly=True, secure=True, samesite='Strict')

A public-facing JavaScript bundle contained a Google API key pattern that should be reviewed for scope and restrictions.

Some frontend keys are expected to be public, but they still need strict domain restrictions and service scoping to avoid abuse and billing exposure.

The scanner matched a Google API key pattern in a production JavaScript asset and flagged it for scope review.

• Restrict the key to the exact production domains.
• Disable unused Google APIs tied to the key.
• Rotate the key if its scope is broader than intended.