CORS & Preflight Auditor

Audit public HTTP(S) API endpoints for the CORS decisions a browser is likely to make. This is aimed at API teams, security reviewers, and QA pipelines that need structured evidence for simple Origin requests and OPTIONS preflights without handing an Actor cookies, credentials, or arbitrary header values.

Each successful URL produces one Dataset row with the observed CORS headers, simple/preflight decisions, redirect evidence, reflection checks, and risk codes.

Minimal input

The smallest raw API input is:

{
  "urls": ["https://example.com/"],
  "testOrigin": "https://app.example.com"
}

With raw API input, omitted optional fields use runtime defaults:

• additionalOrigins=[]
• requestedMethod="POST"
• requestHeaders=[]
• concurrency=4
• timeoutSecs=20
• maxResponseBytes=131072

The Apify Console input schema intentionally prefills an additional reflection probe and common request-header names so an interactive run demonstrates more checks. Those Console prefills are not raw API defaults.

One run accepts 1-20 unique URLs. Larger jobs must be split into multiple runs.

What it checks

• Access-Control-Allow-Origin exact/wildcard/multiple-value behavior;
• exact Access-Control-Allow-Credentials: true semantics;
• OPTIONS status and requested method/header-name allowance;
• CORS-safelisted GET, HEAD, and POST method semantics;
• case-sensitive matching for non-safelisted method tokens;
• the special rule that Access-Control-Allow-Headers: * does not authorize Authorization;
• dynamic Origin reflection across multiple test origins;
• reflected origins without Vary: Origin;
• selected response metadata (Expose-Headers, Max-Age, Vary).

OPTIONS redirects are observed as the original 3xx response and are not followed into a later 2xx. Ordinary GET redirects still use the shared safe fetch path and revalidate every redirect target.

Example result

Private fixed-code run aNdzMyxO9n856XtcY on build 6RzlYA04blFn9cfeb observed this successful PATCH + Authorization policy (abridged):

{
  "requestedUrl": "https://httpbin.org/anything",
  "status": 200,
  "preflightStatus": 200,
  "requestedMethod": "PATCH",
  "requestHeaders": ["authorization"],
  "allowOrigin": "https://app.example.com",
  "allowCredentials": "true",
  "allowHeaders": "authorization",
  "simpleAllowed": true,
  "credentialedSimpleAllowed": true,
  "requestedMethodAllowed": true,
  "requestedHeadersAllowed": true,
  "preflightAllowed": true,
  "credentialedPreflightAllowed": true,
  "riskLevel": "none"
}

This is a cited acceptance sample, not a guarantee that another endpoint will return the same policy.

Safety and failure boundaries

• Public HTTP(S) targets only, ports 80/443.
• DNS results are validated before connecting; GET redirect targets are revalidated.
• Loopback, private, link-local, reserved, and transition targets are rejected.
• No cookies, login, browser automation, arbitrary request headers, proxies, or user-supplied header values.
• Users provide only Origin values, a preflight method, and header names; the Actor constructs the CORS probe headers itself.
• Request count, response bytes, decompression, deadlines, redirects, and concurrency are bounded.
• URL query values are redacted from stored diagnostics.

additionalOrigins are placed only in the Origin header; the Actor does not contact those origin hosts. A failed optional reflection probe does not erase a completed primary + preflight audit.

If the primary or OPTIONS probe fails a network/security/resource check, the Actor emits a diagnostic row but does not charge a cors-audited event. The run-start event still applies. If every selected URL fails, the run is marked FAILED rather than reporting false success.

When an Apify maxTotalChargeUsd budget cannot fund all requested successful audits, the Actor reduces selectedByBudget before doing network work and sets budgetLimited=true in SUMMARY.

Interpretation

origin-reflection means more than one tested Origin was echoed. It is not automatically a vulnerability: a service may intentionally allow several origins. Reflection is more concerning when credentials are allowed, and a reflected response without Vary: Origin is flagged separately because shared caches can mix policy responses.

Access-Control-Allow-Origin: * plus credentials is also reported as a configuration smell; browsers do not treat the wildcard as authorization for a credentialed read.

Pricing

The current private PPE configuration, measured before independent rereview, is:

• Actor start: $0.00025/run
• cors-audited: $0.00030/successfully audited URL
• minimum explicit maxTotalChargeUsd: $0.001

These are Actor event charges. Because a run accepts at most 20 URLs, the arithmetic for fully successful jobs is:

Successful URLs	Required full runs	Actor event charges
1	1	$0.00055
20	1	$0.00625
100	5	$0.03125
1,000	50	$0.31250

The 100- and 1,000-URL rows are executable multi-run arithmetic, not claims that one Actor start can accept those inputs.

Apify platform resource usage is a separate developer-side cost and varies by runtime/network behavior. Fixed-code private samples on build 6RzlYA04blFn9cfeb measured:

• one successful URL: about $0.00014315 platform usage;
• two successful URLs under a $0.001 budget: about $0.00013604 total;
• one rejected loopback URL: about $0.00006418 platform usage.

These are sparse acceptance samples, not P95 claims. At the current 20% Apify margin, the measured failed-run floor is why the start event is $0.00025 rather than the earlier $0.00005: an $0.00005 start would leave only $0.00004 before platform resource cost, below the measured failed-run sample.

Recheck pricing before release if repeated one-URL successful platform usage reaches $0.00030, failed-run usage reaches $0.00016, or the workload/support profile changes materially.

Support

Use the Actor's Apify Issues/support entry for reproducible problems. Include the Apify run ID, the relevant redacted endpoint shape, and expected versus observed CORS behavior; do not paste credentials, cookies, tokens, or sensitive query values.