A fragment identifier is the portion of a URL after the hash symbol that the browser uses locally and does not send to the server. Security teams care about it because browser-only processing can create a state the server never sees, which can be abused in redirect and token-handling flows.
What the fragment identifier actually does
A fragment identifier is the part of a URL that follows the hash symbol and is processed locally by the browser. Because it is not sent to the server, it can influence client-side state, navigation, or script logic without appearing in server logs or request handling.
That local-only behavior is what makes the term security-relevant. A fragment can carry data that a browser or single-page application reads after the initial page load, so the visible URL, server-side routing, and application state can diverge in ways that are easy to miss during review.
Why fragment identifiers matter in web security
The main security concern is not the fragment itself, but the mismatch it can create between what the browser interprets and what the server can observe. That split can become important in redirect flows, token handling, and client-side routing, especially when developers assume the entire URL is equally visible or enforceable.
Fragments are also relevant because they may be used as a carrier for state that should never be exposed in a browser address bar. If a design relies on the client to interpret sensitive values, security reviewers need to understand exactly where that value is consumed and whether it is protected from unintended script access or logic abuse.
Common security failure modes
Fragment identifiers can contribute to security issues when the application treats them as trusted input. A browser-only value can be combined with application logic that performs redirects, reconstructs destination URLs, or extracts token-like data after page load, which creates room for open redirect mistakes, token leakage, or inconsistent authorization decisions.
Another failure mode is visibility mismatch. Teams may believe a value is hidden because it never reaches the server, but it is still visible to the end user, browser extensions, page scripts, and any component that reads location state. That makes it unsuitable for secrets and risky for security decisions that depend on server-side enforcement.
How to reason about fragments during review
When you review a URL-handling flow, treat the fragment as client-side state, not as a transport for trusted security decisions. The key question is which component consumes it, what assumption that component makes, and whether the same outcome can be manipulated by a user changing the URL locally.
For browser-based applications, the practical test is simple: if changing the fragment changes authorization, redirect behavior, session handling, or token processing, then the application is depending on a value that the server never sees. That is usually a design smell and often a review item even when no immediate exploit is obvious.
Risk and Threat Considerations
Fragment identifiers can create security exposure when developers place sensitive state in a part of the URL that only the browser processes. That can lead to token leakage, redirect abuse, or client-side logic manipulation, especially when the fragment is treated as trustworthy input instead of user-controlled state.
Failure mechanism: An attacker or careless implementation can supply a fragment that changes client behavior while bypassing any server-side validation, because the server never receives that portion of the URL.
Impact: The result can be broken redirect logic, unauthorized client-side actions, exposed tokens, or a false sense of security during logging and monitoring.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | URL handling and client-side state affect API and web service trust boundaries. |
| Recommendation — Validate fragment-driven redirect and token flows before release. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Fragments are user-controlled URL input that can steer client logic. |
| Recommendation — Treat fragment values as untrusted input and validate any consumer logic. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | Fragment-based client logic can trigger unsafe downstream API behavior. |
| Recommendation — Prevent client-side fragment values from driving unsafe API requests or redirects. | ||
Practitioner Guidance
Why practitioners should care: The fragment is one of the easiest places for server and browser state to diverge, so it deserves explicit review in any flow that handles redirects, post-login destinations, or browser-managed tokens. If a security decision depends on it, the design usually needs to move that decision server-side or reframe the control boundary.
Common misunderstanding: “Not sent to the server” does not mean “safe by default.” It only means the server cannot enforce or observe it unless the application deliberately reflects or interprets it.