http-cors
No permissive CORS
The sections below are generated from the CLI (methodology 0.3-draft, CLI 0.3.0); the same text is printed by sealmark explain http-cors.
- pack
http- weight
- scored
- scope
- server as deployed (answer to a cross-origin preflight)
- decided by
- http
- since
- 0.2-draft (methodology 0.3-draft)
- config keys
checks.http-cors.enabledchecks.http-cors.severityserver.url
Probes
preflightOPTIONS with Origin: http://sealmark-evil.example and Access-Control-Request-Method: POST (no credentials, as a browser sends it)
Settings and thresholds
Every check also takes checks.http-cors.enabled and checks.http-cors.severity; they are described once in the configuration reference.
This check has no numeric threshold.
| Key | Default | Standard | Meaning |
|---|---|---|---|
server.url | none | not locked | URL of a Streamable HTTP server. Alone it must already be running; with command, Sealmark starts it and waits for this URL. |
How the verdict is established
- Scoring. scored: pass = 1 point, part = 0.5, fail = 0. A fail lowers the pack's percentage but never caps the letter.
What to fix
Do not answer preflights with a wildcard origin; echo back only the specific origins you serve, or send no CORS headers if no browser app calls the server. A preflight answered with a redirect (3xx) is inconclusive: answer the OPTIONS request on the path as configured, or give the URL with the trailing slash the server redirects to.
False positives
A server that is meant to be called from a browser app should allow that one origin, not the probe's.
False negatives
CORS headers sent only on actual requests, or only to some paths.