CORS Protocol Architecture, Preflights & Security Boundaries
Cross-Origin Resource Sharing (CORS) is a browser-enforced security mechanism defined by the W3C and WHATWG. When a client-side application issues a non-simple request (such as a POST with a Content-Type: application/json or custom headers), the user agent first dispatches an HTTP OPTIONS preflight request to inspect the server's permission policies before executing the actual request.
Critical CORS misconfigurations include:
- Wildcard Origin with Credentials: Setting
Access-Control-Allow-Origin: *alongsideAccess-Control-Allow-Credentials: trueis blocked by modern browsers because it exposes authenticated user state to arbitrary origins. - Reflection of Arbitrary Origin Headers: Dynamically echoing back the untrusted
Originrequest header without server-side allowlist verification allows attackers to bypass cross-origin boundaries. - Uncached Preflight Latency: Omitting
Access-Control-Max-Ageforces browsers to repeat the preflight handshake for every API call, adding unnecessary network round-trips.
RFC 2104 HMAC Verification in Payment Webhooks
Payment providers (Stripe, PayPal, VNPay) and developer platforms (GitHub, Slack, Shopify) sign webhook delivery payloads with HMAC (Hash-based Message Authentication Code).
For Stripe, the signature header contains a timestamp t=... and signature v1=... computed over timestamp + "." + rawBody. This prevents replay attacks by ensuring payloads older than the tolerance window (typically 5 minutes) are rejected.
Mitigating Timing Attacks in Webhook Receivers
When verifying cryptographic digests on backend servers, never use standard equality operators (a === b) or string comparison functions that return early upon discovering a non-matching character. Always use constant-time comparison primitives (e.g. crypto.timingSafeEqual in Node.js or subtle.verify in Web APIs) to prevent side-channel timing exploits.