Hackal Run
CORS Misconfiguration Check
Check how your site answers when another origin asks for its resources. It's a quick, passive read of the CORS headers returned by your site root and a list of common API, account, and session paths.
What this checks, and why it matters
Browsers stop one site from reading another site's responses unless that site opts in. Cross-origin resource sharing is how a server opts in: it returns headers naming which origins may read a response, and whether credentials such as cookies are allowed to come along.
CORS becomes risky when it is too permissive. If your server automatically trusts whichever website makes a request, it has effectively approved every site that asks. If it also allows authenticated requests, a malicious website may be able to read sensitive responses using a victim's logged-in session. A related mistake is checking that an origin merely starts with or ends with your domain, which someone can defeat by registering a lookalike name. This check sends a normal request and a preflight with test origins, then reports what comes back.
Cross-origin rules are usually set per route rather than site wide, so the root of a site often returns nothing at all while an API path behind it is wide open. This tool reads the CORS headers returned for your site root and a fixed list of common API, account, and session paths. It reads response headers only, never the response bodies, and it sends no cookies or credentials, so it cannot see any of your data. A path we do not try may still answer differently. It does not crawl your site or API, test authenticated endpoints, or map every route.
Questions
What is CORS?
Cross-origin resource sharing is how a server tells browsers which other origins are allowed to read its responses. Without it, a browser blocks a page on one origin from reading a response that came from another.
What does this check look for?
This check looks for an Access-Control-Allow-Origin that reflects back whatever origin asked, an origin allowlist that can be fooled by a lookalike domain, a wildcard origin combined with credentials, acceptance of the null origin, and a preflight that is more permissive than the plain response. It sends a normal request and a preflight to your site root and a fixed list of common API, account, and session paths, reads the response headers only, and reports what came back.
Why did it check paths that do not exist on my site?
Cross-origin rules are usually applied by middleware that runs before your routes, so a path that returns a 404 still shows the policy your server would use. Checking a list of common API and account paths is how we tell a site with no cross-origin sharing apart from one where the root is quiet but an API is open. Regardless of path, we only read the response headers, never the bodies, and we send no credentials.
Is this a full security audit?
No, just a quick look at how a few common paths answer a cross-origin request, meant as a sanity check when you launch a new site or API. Cross-origin rules are usually set per route, so a path we don't try may answer differently. This doesn't crawl your routes or test authenticated endpoints.
More Hackal Run checks
Beyond the spot-check
The quick look is just the start.
Unlike the tools on this page, the Hackal platform monitors your site's external attack surface continuously, and turns findings into prioritized, plain-English fixes.
See the platform