A client-side application runs on a user’s device or browser and handles part of the user experience locally. In security and identity terms, it can store session state, request tokens, and call APIs directly, which increases exposure to browser attacks, token theft, misconfiguration, and weak client-side controls.
What a client-side application is responsible for
A client-side application is the part of the system that executes on the user’s browser or device and shapes the interactive experience locally. That design shifts some logic away from the server, which improves responsiveness but also moves trust boundaries into an environment the organisation does not fully control.
Because code and state exist closer to the user, the application must assume the browser can be inspected, modified, or influenced by other content on the page. Security problems in this layer often come from unsafe script execution, weak state handling, and overreliance on the client to protect data or enforce decisions.
Why client-side applications change the security model
Client-side delivery changes what attackers can see and touch. Tokens, session state, rendered data, and browser APIs may all be reachable from the user environment, so weaknesses can become visible through script injection, extension abuse, or compromised third-party code. For that reason, browser-facing controls such as Client-Side Security Guide are often as important as server-side hardening.
The main security implication is that the browser is not a trusted execution environment in the same way as a protected backend. If the client can call APIs directly, then authorisation, token scope, and data exposure controls must be enforced server-side, while the client is treated as a hostile or semi-trusted presentation layer.
Common failure modes in the browser
Client-side applications frequently fail when they treat JavaScript, rendered HTML, or browser storage as if they were safe by default. Cross-site scripting, DOM-based injection, weak content handling, and unsafe third-party scripts can turn the browser into an execution point for attackers, which is why robust browser input and output handling matters.
Session and secret handling is another common weakness. Access tokens, API keys, and other sensitive values placed in browser storage or embedded in front-end code can be stolen or reused, especially when the application lacks strong boundary controls. Public client-side exposure is a well-known reason to keep secret material out of shipped code and to avoid over-privileged front-end access paths.
When third-party scripts are involved, the attack surface expands beyond the organisation’s own code. Supply-chain style risks, script tampering, and tag-manager abuse can compromise the page even when the core application itself was written carefully.
How client-side applications should be governed and tested
Security review for client-side applications should focus on the page as delivered, not just on source code review. That means checking what scripts are loaded, what data is exposed to the browser, how tokens are stored and refreshed, and whether the front end can be altered in ways that change the security posture.
Testing should include browser-context attacks, script integrity review, and validation of client-to-API trust assumptions. The most useful question is not whether the page renders correctly, but whether it still behaves safely when scripts are injected, storage is inspected, requests are replayed, or network responses are manipulated.
For organisations that rely on OAuth or direct API access from the browser, the client should be designed around narrow scopes, short-lived credentials, and explicit audience restrictions. This reduces the impact if browser state is observed or stolen, and it keeps the server in control of the real security decision.
Risk and Threat Considerations
Client-side applications are attractive to attackers because they concentrate sensitive interaction, browser state, and trust decisions in a user-controlled environment. The usual failure pattern is not a single bug but a chain, for example script injection, token theft, and API abuse, which can lead to account compromise, data exposure, or fraudulent actions.
Failure mechanism: Attacker-controlled code or content executes in the browser, reads or reuses session material, and then acts through legitimate API calls or user context.
Impact: The result can be session hijacking, unauthorised data access, persistent abuse of browser trust, or compromise that survives until tokens are revoked and the affected client paths are cleaned up.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | V7 — Session Management | Client-side apps often store and use session state in the browser. |
| V10 — OAuth and OIDC | Browser apps commonly request and present tokens directly to APIs. | |
| V8 — Authorization | Client-side requests still depend on server-enforced access decisions. | |
| Recommendation — Harden browser session handling and limit what client-side state can be reused if exposed. Use browser-safe OAuth and OIDC patterns with narrow scopes and strict token handling. Enforce authorisation on the server and never trust client-side checks as the final decision. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Browser code may request data directly, but access must be enforced centrally. |
| Recommendation — Enforce access decisions at the system boundary rather than in client-side logic. | ||
Practitioner Guidance
Why practitioners should care: Treat the client as an exposure surface, not a trust anchor. If the application stores state or requests tokens locally, the real security boundary shifts to how carefully the browser environment is constrained and what the server will still verify on every request.
What to watch for: Overly broad token scope, long-lived browser state, third-party script sprawl, and direct exposure of secrets in front-end assets are the conditions that most often turn a modern web app into a compromise path.
Practitioner takeaway: Secure client-side applications by designing for browser compromise assumptions, then make the server authoritative for identity, access, and sensitive data decisions.
Related resources from NHI Mgmt Group
- How should teams protect client-side application code from reverse engineering?
- How should security teams protect client-side JavaScript without breaking the application?
- How should security teams limit session lifetime after a client-side compromise in an application environment?
- Why does client-side verification matter in desktop application update workflows?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org