Web App

How web apps work

A web app runs in the browser but depends on a server-side application stack to process requests, enforce business logic, and persist data. That split matters because the browser is only one trust boundary: the app still has to authenticate users, manage state across requests, and protect the server endpoints that the browser invokes.

In practice, the browser becomes the presentation and interaction layer, while the server becomes the control point for data access, workflow decisions, and session handling. That is why a web app is not just a website with buttons, it is a distributed application with security decisions spread across client and server components.

Security properties of the browser and server boundary

The browser is convenient, but it is not a trusted execution environment for sensitive logic. Anything delivered to the client can be inspected, modified, replayed, or bypassed, so a secure web app must assume that client-side checks are advisory at best. Server-side validation remains the authoritative control for permissions, data access, and workflow integrity.

This boundary also shapes session security. Cookies, tokens, and browser storage are often the bridge between the user and the server, which means weak handling can expose sessions to theft, fixation, or replay. Blazor Security Guide is a useful example of how render modes, antiforgery, and circuit hardening become part of the application trust model rather than optional extras.

Common web app controls and failure points

Because web apps rely on HTTP request handling, they are exposed to familiar control failures such as broken authentication, broken authorisation, cross-site request forgery, injection flaws, insecure direct object reference patterns, and unsafe session handling. The technical surface is broad because every user action can become a request, and every request can become a security decision.

For that reason, secure design usually means validating input on the server, separating presentation from authority, protecting session identifiers, and ensuring that sensitive actions are not controlled only by hidden fields, client code, or assumptions about user behaviour. Web Application Security Testing Guide is directly relevant because it maps the main testing areas that expose these failures, including authenticated testing and manual checks.

Web apps in real deployments

Real-world web apps often sit behind additional layers such as reverse proxies, load balancers, content delivery networks, identity providers, and API back ends. Those layers can improve scale and resilience, but they also add dependency chains that must be secured and observed as part of the application, not treated as separate concerns.

Deployment context changes the risk profile too. A web app used in a kiosk, shared device, or managed workspace may need stricter session clearing and interface constraints than the same application used on a personal device. Kiosk and Shared Device Security Guide is a good fit when the browser is part of a shared access model, because session persistence and device lockdown become application-security issues.

Risk and Threat Considerations

Web apps are high-value targets because they are exposed to users, browsers, and network traffic at the same time. The most common risks come from trust placed in client-side code, weak session controls, and server-side flaws that let attackers read, change, or execute application behaviour they should not reach.

Failure mechanism: Attackers exploit the browser-server split by tampering with requests, abusing sessions, or targeting server endpoints that assume the client has already enforced a rule. When those assumptions fail, the app can leak data, bypass authorisation, or execute unintended actions.

Impact: A compromised web app can expose sensitive records, account sessions, workflow actions, or administrative functions, and it can become a foothold for broader compromise if the server-side logic or connected services are weakly protected.

Practitioner Guidance

Why practitioners should care: The security of a web app is determined less by how it looks in the browser and more by whether the server makes every important decision itself. Treat client-side code as user-facing convenience, not as a security control.

Common misunderstanding: A polished UI or a modern framework does not make the application secure. The real question is whether authentication, authorisation, session control, and data validation still hold when a request is modified, replayed, or submitted outside the intended flow.

Practitioner takeaway: Test the app as a distributed system, not just a front end, and review every browser-to-server trust assumption as a potential control failure.

Related resources from NHI Mgmt Group

• How should organisations enforce privacy choices across web, app, and connected TV experiences?
• What breaks when web app testing only looks for vulnerabilities instead of exploitability?
• Why do mobile apps create governance risk beyond standard web app controls?
• How do you know if logout is working properly in a web app?