CORS Policy Risk
NullFault checks whether public endpoints return permissive Access-Control-Allow-Origin headers that could let untrusted sites read browser-authenticated API responses.
What NullFault Checks
- Whether API-like routes return permissive cross-origin headers to untrusted origins.
- Whether credentials appear allowed together with wildcard or reflected origins.
- Whether the response is a meaningful API response rather than a blocked request, login page, or app fallback.
Why It Matters
- CORS controls which websites can read responses from your API in a user's browser.
- A permissive policy can expose account data when combined with cookies, bearer tokens, or other browser-held credentials.
- Overbroad CORS often appears during development and accidentally survives launch.
Common Causes
- Setting Access-Control-Allow-Origin to * to make development easier.
- Reflecting the request Origin back while also allowing credentials.
- Leaving localhost, preview, or staging origins allowed in production.
Check it yourself
Inspect an API response in DevTools and read Access-Control-Allow-Origin and Access-Control-Allow-Credentials. A wildcard or reflected origin with credentials deserves review.
Mitigation
- Allow only the exact production origins that need browser access.
- Never combine credentialed requests with wildcard or reflected origins.
- Separate public unauthenticated APIs from user-specific APIs with stricter CORS rules.
- Test preview, staging, and production origins explicitly before launch.
Reality check
CORS findings need context. A public read-only endpoint can intentionally allow broad access; a user-specific endpoint usually should not.