How should security teams structure web and API responsibilities in modern application architectures?

Why This Matters for Security Teams

Modern application stacks split trust across the browser, backend services, and machine-to-machine calls, but many teams still treat them as one security problem. That creates confusion over where authentication ends, where authorization begins, and who is accountable when a client is compromised. NIST’s control baseline for system and communications protection, especially in NIST SP 800-53 Rev 5 Security and Privacy Controls, reinforces that control placement should reflect the actual trust boundary, not the deployment diagram.

The practical risk is that the web layer becomes a policy blind spot while the API quietly becomes the real enforcement point. If the browser stores tokens carelessly, or if the API trusts client-side claims without re-checking context, attackers can move from session abuse to direct data access. NHIMG’s Ultimate Guide to Non-Human Identities notes that 97% of NHIs carry excessive privileges, which is exactly the kind of overreach that turns an exposed token into a full application compromise.

Security teams get the cleanest outcomes when they accept that the browser is an untrusted execution environment and the API is the place where decisions must be final. In practice, many security teams discover that boundary only after a token leak, broken object-level authorization, or an exposed admin endpoint has already caused damage.

How It Works in Practice

The web application and the API should have different responsibilities even when they are developed by the same product team. The browser-facing layer should handle session initiation, user interaction, and safe token transport, but it should not make final access decisions. The API should verify identity, apply authorization, enforce object- and action-level rules, and produce logs that can support audit and incident response. That separation makes it harder for a compromised client to turn presentation logic into privilege escalation.

In practice, the API should validate every request as if it came from an untrusted caller. That means checking the token, the audience, the scope, the tenant, the user or workload context, and the specific resource being requested. The browser can cache state for usability, but it should not be treated as a source of truth for entitlement. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with this model because access control, auditing, and session protections are most effective when enforced at the service boundary.

For NHI-heavy architectures, the same split matters for service accounts, API keys, and automation tokens. NHIMG’s The State of Non-Human Identity Security shows how visibility gaps and weak rotation make secrets a recurring weakness, so teams should reduce what the web layer ever sees and keep privileged decisions in the API or gateway. A common implementation pattern is:

• Use the web layer for session handling and token relay only.
• Put RBAC, ABAC, or policy-as-code checks in the API.
• Validate object ownership and tenancy at request time.
• Log the decision, not just the request.
• Keep secrets and long-lived credentials out of browser storage.

These controls tend to break down when front-end code is allowed to call internal APIs directly without a policy gateway, because the browser then becomes a privilege-bearing control plane.

Common Variations and Edge Cases

Tighter separation often increases implementation overhead, requiring organisations to balance developer convenience against stronger enforcement and clearer auditability. That tradeoff is real in single-page apps, mobile clients, server-side rendering, and mixed monolith-plus-API environments, where teams may be tempted to duplicate checks in the client for speed. Current guidance suggests that duplication should improve user experience, not replace enforcement.

There is also no universal standard for how much authorization logic belongs at the edge versus in the API itself. Some organisations use an API gateway for coarse filtering and move fine-grained authorization into services; others centralise policy in a shared authorization service. The important point is consistency: the browser should not decide access, and the API should not rely on mutable UI state. For additional operational context, McDonald's McHire AI Chatbot Default Credentials is a useful reminder that exposed credentials and weak boundary design can turn a public-facing system into a large-scale data exposure.

Teams should also treat service-to-service calls as a separate trust layer from end-user sessions. A browser session proves a user intent, while an API token or workload credential proves a calling component, and those are not interchangeable. When that distinction is blurred in legacy systems, separation degrades into duplicated checks, inconsistent claims, and hidden admin paths.

Related resources from NHI Mgmt Group

• How should security teams modernise SAML-based web apps for API-first architectures?
• How should healthcare security teams manage expanding API and web application attack surfaces?
• How should security teams adapt dynamic application security testing for API driven and web 3.0 environments?
• How should security teams use exploit validation to prioritise vulnerability remediation in web application and API environments?