What Are Fetch Metadata Request Headers?
Fetch Metadata Request Headers are HTTP headers that browsers automatically send with every request, providing servers with valuable context about where and how a request originated. Introduced through the W3C Fetch Metadata specification, these headers help websites distinguish between legitimate cross-origin requests and potentially malicious attacks.
Unlike traditional security headers that require manual implementation, fetch metadata headers work automatically in compliant browsers. This means servers can immediately benefit from enhanced security intelligence without any changes to client-side code. For organizations focused on comprehensive security strategies, these headers provide an additional layer of protection without deployment overhead.
The four main headers are:
- Sec-Fetch-Site: Relationship between initiator and target origin
- Sec-Fetch-Mode: The mode of the request
- Sec-Fetch-Dest: The intended destination of the request
- Sec-Fetch-User: Whether navigation was user-initiated
Each header provides specific information about request context
Sec-Fetch-Site
Indicates the relationship between request origin and target: same-origin, same-site, cross-site, or none.
Sec-Fetch-Mode
Describes the request mode: navigate, cors, no-cors, same-origin, or websocket.
Sec-Fetch-Dest
Shows the intended destination: document, script, style, image, fetch, worker, and more.
Sec-Fetch-User
Boolean indicating user-initiated navigation (?1) vs programmatic navigation (absent).
Sec-Fetch-Site in Detail
The Sec-Fetch-Site header is one of the most valuable for security validation. It indicates the relationship between the request's initiator and the target origin:
| Value | Description |
|---|---|
| same-origin | Same scheme, host, and port as the target |
| same-site | Same registrable domain (subdomains count) |
| cross-site | Different domain entirely |
| none | Direct user-initiated (address bar, bookmark) |
For sensitive operations like password changes or payment processing, checking that Sec-Fetch-Site is 'same-origin' or 'same-site' provides strong protection against cross-site request forgery attacks. This security measure is particularly important for e-commerce and financial websites handling sensitive transactions.
Understanding the difference between same-origin and same-site is crucial for proper security configuration. A same-origin request matches on scheme, host, and port, while same-site only requires the same registrable domain.
Why Fetch Metadata Headers Matter for Security
Fetch metadata headers provide a powerful defense against several common web attacks. By analyzing these headers, servers can make informed decisions about whether to allow or reject requests. This approach complements traditional security measures and adds an extra layer of protection for your web applications. Implementing these checks is a key component of technical SEO security audits that help maintain site trustworthiness.
CSRF Protection
Cross-Site Request Forgery attacks trick users into performing unintended actions. With fetch metadata, you can detect cross-origin requests to sensitive endpoints and block them before processing.
XSSI Prevention
Cross-Site Script Inclusion attacks try to steal data by including API responses as scripts. Validate Sec-Fetch-Dest to ensure requests match expected resource types.
Timing Attack Mitigation
Timing attacks measure response times to infer system state. Monitor header patterns to identify and rate-limit suspicious probing attempts.
Implementing Server-Side Handling
Implementing fetch metadata header validation requires server-side configuration. Below are common approaches for different server environments. Our web development team regularly implements these security measures for client applications, ensuring robust protection against cross-origin attacks while maintaining legitimate traffic flow.
1# Block cross-site POST requests to sensitive endpoints2location /api/sensitive/ {3 if ($http_sec_fetch_site !~ "^(same-origin|same-site)$") {4 return 403;5 }6}7 8# Validate request destination for API endpoints9location /api/ {10 if ($http_sec_fetch_dest !~ "^(fetch|cors)$") {11 return 403;12 }13}1const fetchMetadataGuard = (allowedModes = ['same-origin', 'same-site']) => {2 return (req, res, next) => {3 const site = req.get('Sec-Fetch-Site');4 const dest = req.get('Sec-Fetch-Dest');5 6 // Check site for sensitive operations7 if (req.method !== 'GET' && !allowedModes.includes(site)) {8 return res.status(403).json({ 9 error: 'Cross-site requests blocked' 10 });11 }12 13 // Validate expected destination14 const allowedDests = ['fetch', 'cors'];15 if (!allowedDests.includes(dest)) {16 return res.status(403).json({ 17 error: 'Invalid request destination' 18 });19 }20 21 next();22 };23};| Browser | Version | Release Date |
|---|---|---|
| Chrome | 76+ | July 2019 |
| Firefox | 90+ | July 2021 |
| Safari | 16.4+ | March 2023 |
| Edge | 79+ | January 2020 |
Frequently Asked Questions
Sources
-
W3C Fetch Metadata Request Headers - Official W3C specification defining the complete standard for fetch metadata headers.
-
MDN Web Docs - Sec-Fetch-Site Header - Comprehensive MDN documentation with browser compatibility matrix and practical examples.
-
Web.dev - Protect Your Resources with Fetch Metadata - Google's developer guide on using fetch metadata for web security protection.