Photo by Zulfugar Karimov on Unsplash

Modern web applications increasingly push business logic into the frontend.

React, Angular, Vue, SPAs, mobile-hybrid applications, GraphQL-driven interfaces, and API-first architectures have transformed how applications are built.

This shift brought major benefits:

• faster UI responsiveness;
• improved user experience;
• reduced backend rendering complexity;
• and rapid development velocity.

But it also reinforced one of the most dangerous recurring security failures in modern enterprise applications:

trusting the client.

More specifically:
trusting the browser to enforce authorization.

And despite decades of security guidance from organizations like the OWASP Foundation, this mistake still appears surprisingly often in production enterprise environments.

OWASP Has Been Warning About This for Years

OWASP explicitly states:

“Access control is only effective in trusted server-side code...” (OWASP Foundation)

OWASP’s client-side security guidance also warns against:

• broken client-side access control;
• sensitive data stored client-side;
• and excessive trust in browser-side logic. (OWASP Foundation)

The core principle is simple:

the browser is not trusted infrastructure.

Anything stored client-side can potentially be:

• modified;
• replayed;
• intercepted;
• tampered with;
• or manipulated.

This includes:

• localStorage;
• sessionStorage;
• JavaScript variables;
• hidden fields;
• cached API responses;
• role objects;
• feature flags;
• and frontend authorization state.

Yet many applications still blur the distinction between:

• presentation logic and
• authorization logic.

That distinction is absolutely critical.

Presentation Logic vs Authorization Logic

Frontend applications are allowed to:

• show menus;
• hide buttons;
• disable UI components;
• optimize user experience;
• and improve usability.

But the frontend must never become the final authority for:

• access control;
• privilege validation;
• role enforcement;
• or trust decisions.

Consider a common frontend pattern:

if (user.role === "admin") {
     showAdminPanel();
} 

By itself, this is not necessarily dangerous.

The problem appears when the backend also implicitly trusts that frontend state.

If backend APIs fail to independently validate authorization server-side, then modifying browser-side state may potentially expose privileged functionality.

At that point, the browser effectively becomes part of the trust boundary.

And browsers are terrible trust boundaries.

Hidden Functionality Is Not Protected Functionality

One of the most common misconceptions in frontend-heavy applications is:

“If users cannot see the button, they cannot access the functionality.”

This is dangerously false.

Attackers do not interact with applications the same way ordinary users do.

They inspect:

• API requests;
• JavaScript bundles;
• network traffic;
• hidden routes;
• GraphQL queries;
• cached responses;
• and client-side objects.

If privileged operations exist backend-side without proper authorization enforcement, simply hiding them in the UI provides little protection.

Security through obscurity is not authorization.

Why localStorage Is Especially Dangerous

OWASP testing guidance specifically warns organizations to review whether sensitive information is being stored client-side. (OWASP Foundation)

Developers frequently store:

• role indicators;
• access levels;
• feature flags;
• tenant identifiers;
• JWTs;
• permission objects;
• or authentication context

inside browser storage.

The issue is simple:

localStorage is fully user-controlled.

Users can modify it directly through:

• browser developer tools;
• JavaScript console access;
• extensions;
• intercepting proxies;
• or injected scripts.

OWASP mobile and client-side security guidance explicitly states:

“Assume all client-side controls can be bypassed...” (OWASP Cheat Sheet Series)

That single sentence summarizes the entire problem.

Applications must always assume:
everything in localStorage is attacker-controlled input.

Because it is.

Broken Access Control Remains the #1 OWASP Risk

OWASP A01:2021 — Broken Access Control remains one of the most severe categories in the OWASP Top 10. (OWASP Foundation)

Why?

Because authorization failures directly affect:

• confidentiality;
• integrity;
• privilege boundaries;
• and trust relationships.

Unlike many vulnerabilities that require chaining or highly specialized exploitation, authorization flaws often provide immediate access to:

• sensitive data;
• privileged workflows;
• administrative functionality;
• or internal business operations.

Recent research continues confirming how widespread and dangerous these flaws remain.

The BACFuzz research project discovered dozens of previously unknown Broken Access Control vulnerabilities in real-world web applications. (arXiv)

Additional academic work on BOLA (Broken Object Level Authorization) similarly demonstrated how modern APIs frequently expose authorization weaknesses through manipulated identifiers and weak trust-boundary enforcement. (arXiv)

This is not a rare edge case.

It is an industry-wide architectural problem.

Real-World Examples Keep Appearing

Broken Access Control issues repeatedly affect major platforms and enterprise applications.

Examples documented publicly include:

• Facebook Business Manager privilege escalation via manipulated request parameters;
• Instagram private-content exposure through weak authorization enforcement;
• ride-sharing applications exposing trip details through IDOR/BOLA weaknesses;
• and enterprise API authorization failures affecting privileged workflows. (Medium)

In many cases, the vulnerabilities were not caused by advanced exploitation.

They were caused by flawed trust assumptions.

Modern SPAs Increased the Risk Surface

Single Page Applications fundamentally changed the threat model.

Large portions of business logic now execute in:

• JavaScript bundles;
• frontend state-management systems;
• client-side routing;
• and browser-side orchestration layers.

This creates pressure to:

• expose more APIs;
• move more logic client-side;
• and optimize UX through frontend state handling.

If backend authorization discipline weakens even slightly, the frontend becomes a dangerous attack surface.

Modern API ecosystems made this even worse.

Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA) are now among the most critical API security risks because APIs often expose:

• user identifiers;
• tenant identifiers;
• object references;
• role metadata;
• or authorization assumptions

that attackers can manipulate if backend validation is insufficient. (arXiv)

Enterprise Systems Are Especially Vulnerable

The consequences become even more severe in enterprise environments involving:

• ERP systems;
• sustainability platforms;
• HR portals;
• vendor systems;
• CRM integrations;
• financial workflows;
• and internal operational applications.

These systems frequently expose:

• supplier data;
• operational metrics;
• governance information;
• compliance evidence;
• identity relationships;
• and privileged workflows.

A single authorization failure can therefore affect:

• operations;
• compliance;
• financial integrity;
• or regulatory exposure.

The danger is amplified when organizations underestimate “secondary” applications such as:

• internal portals;
• vCard/contact-sharing systems;
• sustainability dashboards;
• or lightweight business tools.

Attackers do not care whether a platform was considered “non-critical.”

They care whether it expands access.

Why This Problem Persists

If the risks are so well understood, why does this keep happening?

Several recurring causes appear repeatedly across enterprise environments.

1. Frontend-heavy development culture

Modern frameworks encourage moving more logic client-side.

This improves responsiveness and development velocity, but also encourages accidental trust leakage into the browser.

2. Weak secure-design review

Many organizations perform:

• vulnerability scanning;
• SAST;
• dependency review;
• and penetration testing.

But they never perform deep trust-boundary analysis.

As a result, insecure architectural assumptions survive all the way into production.

3. Business pressure and rapid delivery

Authorization shortcuts often begin as:

• temporary workarounds;
• MVP decisions;
• or demo-driven implementations.

Over time, these shortcuts quietly evolve into production dependencies.

4. Authentication and authorization are confused

This remains extremely common.

Authentication answers:

“Who are you?”

Authorization answers:

“What are you allowed to do?”

Those are completely different security problems.

Many applications implement login correctly, then accidentally trust client-side state for authorization decisions.

That is where the collapse begins.

Secure Design Principles

Several principles remain essential.

1. The browser is hostile territory

Always assume:

• client-side state is attacker-controlled.

Because it is.

2. Authorization must always be enforced server-side

Every privileged backend operation must independently validate:

• identity;
• permissions;
• role;
• ownership;
• and access scope.

Never trust frontend role indicators alone.

3. Frontend controls are usability features — not security controls

Hidden buttons are not authorization.

Disabled UI elements are not authorization.

Frontend route guards are not authorization.

Only backend enforcement is authorization.

4. Perform trust-boundary reviews early

The most dangerous authorization failures are often architectural, not implementation-level bugs.

Threat modeling and trust-boundary analysis should happen:

• before development, not merely
• after deployment.

Final Thoughts

Modern enterprise security failures increasingly emerge not from exotic zero-days, but from fundamental trust-model mistakes.

The browser is one of the most dangerous places to place trust.

Yet many applications continue treating it as if it were part of the security perimeter.

It is not.

Frontend frameworks will continue evolving.
SPAs will continue dominating development.
Client-side logic will continue expanding.

But one principle remains unchanged:

authorization decisions must never depend on user-controlled state.

The browser is not a security boundary. (OWASP Foundation)

The rise of "vibe coding" and AI-assisted development may also make this problem easier to introduce accidentally.

When developers rapidly generate frontend-heavy code, dashboards, admin panels, CRUD apps, and internal tools with AI assistance, security boundaries can become blurred. Generated code may appear functional, polished, and production-ready while still embedding dangerous assumptions such as:

• trusting client-side role flags;
• hiding privileged UI elements instead of enforcing backend checks;
• storing authorization state in localStorage;
• exposing overly broad API endpoints;
• or confusing authentication with authorization.

This does not mean AI-assisted development is inherently unsafe. It means generated code must still go through the same secure-design review, threat modeling, backend authorization checks, and adversarial testing as human-written code.

As AI lowers the cost of building applications, it may also lower the barrier to shipping insecure applications faster.

That makes one principle even more important:
the browser is still not a security boundary, even if the code was generated beautifully.