Request header
> Sec-Fetch-User: ?1Sec-Fetch-User Header: ?1 and User Activation
Sec-Fetch-User is always ?1 and appears only on user-activated navigations, like a link click. When it is absent and why Safari does not send it.
- Direction
- Request
- Category
- Security
- JS can set it
- No: forbidden header name
- Note
- Safari does not send it
TL;DR:
Sec-Fetch-User: ?1is sent only on navigation requests the user caused with a click, keypress or similar activation. It is absent otherwise, never?0. Safari does not send it, so use it as a soft signal, never a requirement.
What it looks like
GET /dashboard HTTP/1.1
Host: example.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Sec-Fetch-User: ?1The value comes from structured-field booleans: ?1 is true. The Fetch Metadata spec (section 2.4) says the header is set only when a request is a navigation and its user-activation flag is true; in every other case the browser omits it. It is a forbidden request header, so scripts cannot add it.
When you will see it
| Action | Sent |
|---|---|
| Click a link | Yes |
| Submit a form with a click or Enter | Yes |
| Type a URL or use a bookmark | Yes, with Sec-Fetch-Site: none |
Page script sets location.href with no gesture | No |
<img>, fetch(), <script>, iframe subresources | No |
The spec scopes it to navigation requests, which is why it is of limited use on its own. It matters when you want to separate “user clicked through to my page” from “a page redirected the browser to mine automatically”.
Uses
- Logging and analytics. Tell real clicks from auto-redirects and prefetch-like navigations in access logs. Log it with
Sec-Fetch-Site. - Tightening a cross-site navigation rule. The standard resource isolation policy allows any cross-site
GETnavigation. If you want stricter, requireSec-Fetch-User: ?1for cross-site navigations to sensitive pages and send others to a landing page. Accept that Safari users, who do not send the header, will always take the landing page, so this is only suitable where that is acceptable. - Clickjacking and drive-by navigation hints. A navigation to your sensitive URL without user activation, from another site, is suspicious. It is a signal, not a defence.
frame-ancestorsin Content-Security-Policy is the defence.
Browser support
Chrome and Edge 76, Firefox 90. Safari: no support in MDN’s compatibility data, with WebKit bug 247697 open for it. This differs from Sec-Fetch-Site, Sec-Fetch-Mode and Sec-Fetch-Dest, which Safari has sent since 16.4. Sent only on requests to potentially trustworthy URLs (HTTPS, localhost).
Related
- Sec-Fetch-Site for the resource isolation policy, Sec-Fetch-Mode, Sec-Fetch-Dest
Frequently asked questions
What does Sec-Fetch-User: ?1 mean?
?1 is the structured-field syntax for boolean true. The browser sends it only when a navigation request was triggered by user activation, such as a click or a keypress. The header has no other value: when the navigation was not user-activated, the browser leaves the header out entirely instead of sending ?0.
Is Sec-Fetch-User sent on fetch() or image requests?
No. The spec defines it for navigation requests only, so subresource requests never carry it. A navigation made by a script, such as location.href set outside a user gesture, or a redirect the page performs on load, will not have it.
Does Safari send Sec-Fetch-User?
Not as of MDN browser-compat-data today. Chrome and Edge 76 and Firefox 90 send it; Safari sends the other three Sec-Fetch headers from 16.4 but has no Sec-Fetch-User support, and WebKit tracks the work in bug 247697. Never make it a required signal.
Can I use Sec-Fetch-User to block bots?
No. Only unmodified browsers are bound by the Sec- prefix. Any script or HTTP client can send Sec-Fetch-User: ?1 with a hand-written request. It is a hint about how a genuine browser got to your URL, not proof of a human.
Sources
Related
Sec-Fetch-Dest Header: All Values Explained
Sec-Fetch-Dest tells the server where a response will be used: document, iframe, image, script, empty. Full value list and server-side uses.
Sec-Fetch-Mode Header: Values and Server Use
Sec-Fetch-Mode reports the request mode: navigate, cors, no-cors, same-origin or websocket. What sets each value and how servers use it.
Sec-Fetch-Site Header: Block Cross-Site Requests
Sec-Fetch-Site says whether a request is same-origin, same-site, cross-site or user-initiated. Resource isolation policy for Express and nginx, plus CSRF use.
Origin Header
Learn how the Origin header identifies where cross-origin requests come from. Essential for CORS security policies and preventing cross-site request forgery.