Forem: Anonymous Security Researcher

The Browser Is Not a Security Boundary

Anonymous Security Researcher — Sun, 10 May 2026 15:42:07 +0000

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.

The Enterprise Security Risks Hiding in Plain Sight

Anonymous Security Researcher — Sat, 09 May 2026 11:22:06 +0000

Executive Summary

In 2026, I privately disclosed multiple high-severity security concerns affecting systems associated with SIPEF Group, a multinational agro-industrial company operating across Southeast Asia, Africa, and Europe. SIPEF is publicly listed in Belgium and is jointly controlled by AvH - Ackermans & van Haaren NV and Group Bracht.

The findings included:

a severe Broken Access Control condition affecting the GeoSIPEF sustainability and traceability platform;
publicly indexed credential-exposure indicators associated with enterprise authentication environments;
indicators potentially consistent with infostealer-related compromise scenarios affecting enterprise identities and sessions;
and additional security concerns involving a digital vCard/contact-sharing application associated with the broader enterprise ecosystem.

The issues were disclosed privately under responsible disclosure principles. Following notification, the organization acknowledged receipt, initiated internal triage and containment activities, engaged external specialists, and temporarily disabled affected systems during investigation and remediation activities.

This article intentionally omits exploit-ready details, credentials, sensitive infrastructure information, employee identities, and technical information that could facilitate misuse.

The purpose of this writeup is to discuss:

architectural security lessons;
identity-centric compromise risks;
secure authorization design;
and governance challenges increasingly faced by modern enterprises.

Background

The investigation began through OSINT-based review of publicly visible exposure indicators and externally indexed authentication-related metadata associated with SIPEF-related systems.

The observed indicators included:

enterprise email addresses;
authentication-related URLs;
environment identifiers;
and credential-exposure records indexed in external exposure-intelligence sources.

Examples of publicly visible environment references included:

/GP/Account/LogOn;
production and UAT environment naming patterns;
Microsoft Online authentication contexts;
and enterprise-related login references.

No credentials were purchased, unlocked, validated, or used.

No unauthorized access attempts were performed at any stage.

The findings were handled strictly within responsible disclosure boundaries.

Broken Access Control in GeoSIPEF

One of the most severe findings involved the GeoSIPEF sustainability and traceability platform.

GeoSIPEF was publicly positioned as a digital sustainability and supply-chain traceability initiative supporting ESG and EUDR-related operational visibility.

During review, the application appeared to rely on client-side authorization state stored within browser-accessible storage mechanisms rather than enforcing authorization decisions entirely server-side.

In practical terms, privilege-related state appeared to be trusted on the client side.

This represents one of the most dangerous anti-patterns in modern web security.

Why Client-Side Authorization Is Dangerous

Frontend applications must never be trusted as authorization boundaries.

Anything stored client-side:

localStorage;
sessionStorage;
JavaScript variables;
browser state;
hidden fields;
or client-generated role objects

can potentially be modified by authenticated users.

Authorization decisions must always be enforced server-side.

If authorization logic depends on tamperable client-side state, authenticated low-privileged users may potentially escalate privileges simply by modifying browser-side values.

This category falls under:

OWASP A01:2021 — Broken Access Control.

Broken Access Control consistently remains one of the highest-impact vulnerability classes because it directly affects:

confidentiality;
integrity;
authorization boundaries;
and trust relationships.

Architectural Lessons from GeoSIPEF

The GeoSIPEF case demonstrates several broader architectural lessons relevant across the industry.

1. Frontends are presentation layers — not trust boundaries

Modern SPAs and JavaScript-heavy applications often push excessive logic client-side.

While this improves responsiveness and developer velocity, it creates serious risk if developers blur the distinction between:

UI state and
authorization state.

The browser must always be treated as hostile territory.

2. Sustainability and ESG platforms are now high-value targets

Modern ESG, traceability, and sustainability systems increasingly contain:

supplier data;
operational metrics;
compliance evidence;
land-use information;
audit trails;
and governance reporting.

As organizations digitize sustainability workflows, these systems become increasingly sensitive operational platforms rather than merely “reporting tools.”

Security maturity must evolve accordingly.

3. Governance failures are often architectural failures

Many enterprise security incidents do not originate from advanced attackers.

They originate from:

insecure architectural assumptions;
weak trust-boundary modeling;
rushed development;
insufficient secure-design review;
and lack of server-side authorization validation.

The most dangerous vulnerabilities are often conceptually simple.

Credential Exposure Indicators

Separate from the authorization issue, additional OSINT review identified publicly visible credential-exposure indicators associated with SIPEF-related identities and authentication environments.

The indicators referenced:

Microsoft Online authentication contexts;
enterprise email addresses;
production and UAT naming patterns;
and ERP-related login environments.

Observed indicators suggested possible exposure involving:

enterprise identities;
browser-stored credentials;
or authentication artifacts.

Again:

no credentials were unlocked;
no credentials were validated;
and no login attempts were performed.

The findings were based entirely on publicly visible metadata and exposure indicators.

Infostealer Malware and Modern Identity Risk

Further analysis suggested that at least part of the observed exposure patterns may have been consistent with modern infostealer-related compromise scenarios.

Infostealer malware has become one of the most significant threats facing enterprises today.

Unlike traditional malware focused solely on destruction or ransomware deployment, infostealers specialize in quietly harvesting:

saved browser credentials;
cookies;
refresh tokens;
browser profiles;
cryptocurrency wallets;
VPN credentials;
cloud sessions;
and authentication artifacts.

The resulting datasets are frequently aggregated and redistributed through underground ecosystems.

Why Password Resets Alone Are Sometimes Insufficient

One important industry misconception is that identity compromise equals “password compromise.”

Modern session-centric compromise changes that equation significantly.

If session cookies, refresh tokens, or persistent browser sessions are compromised, attackers may potentially:

bypass certain MFA workflows;
inherit already-authenticated sessions;
or maintain access even after password changes if sessions are not invalidated properly.

This means organizations increasingly need to treat incidents as:

identity compromise events, not merely
password reset events.

Potential Enterprise Impact Areas

Modern identity-centric compromise can potentially affect far more than email access.

Depending on environment integration, risks may extend into:

ERP systems;
VPN environments;
SaaS platforms;
document-management systems;
cloud consoles;
HR systems;
procurement systems;
and financial workflows.

Organizations should therefore consider:

session invalidation;
token revocation;
OAuth consent review;
endpoint forensics;
privileged access review;
and identity telemetry analysis.

Security Concerns in a Digital vCard / Contact-Sharing Application

Separate review activities also identified security concerns affecting a digital vCard/contact-sharing application associated with the broader enterprise ecosystem.

The issues observed were not limited to a single isolated vulnerability pattern, but rather reflected broader concerns around:

trust-boundary enforcement;
client-side assumptions;
exposure of sensitive business-contact information;
and insufficient defensive controls around authenticated application behavior.

Because digital business-card and contact-sharing platforms frequently integrate with:

corporate identity systems;
email environments;
CRM workflows;
and mobile-device ecosystems,

security weaknesses in such applications may create disproportionate downstream risk relative to their perceived operational importance.

Why Digital Identity and Contact Platforms Matter

Enterprise contact-sharing systems are often underestimated from a security perspective.

In reality, they may expose:

employee names;
titles;
reporting structures;
phone numbers;
email addresses;
organizational relationships;
and internal business metadata.

This information can become highly valuable for:

phishing campaigns;
Business Email Compromise;
social engineering;
credential-targeting operations;
and identity correlation activities.

Even seemingly “low-risk” applications can therefore materially increase enterprise attack surface.

Common Architectural Weaknesses in Enterprise Applications

Several recurring anti-patterns commonly appear in internally developed or rapidly deployed enterprise web applications:

excessive trust in client-side state;
insufficient server-side authorization validation;
predictable identifiers or object references;
inadequate segregation between environments;
weak session invalidation controls;
overexposed API responses;
and insufficient input or access validation.

These weaknesses often emerge when:

security review occurs too late in the SDLC;
applications evolve organically without formal architecture review;
or business functionality is prioritized ahead of trust-boundary modeling.

Identity Exposure and Enterprise Reconnaissance Risk

Attackers increasingly combine:

publicly exposed contact information;
credential-exposure datasets;
LinkedIn profiling;
breached browser data;
and cloud identity information

to construct highly accurate targeting maps of organizations.

Applications that expose employee relationship structures, contact metadata, or organizational mappings may unintentionally assist:

phishing operators;
infostealer operators;
BEC actors;
or credential-harvesting campaigns.

This becomes especially concerning when combined with:

weak MFA adoption;
session-token theft;
browser credential storage;
or credential reuse across platforms.

Incident Response and Forensic Considerations

One of the most important lessons from incidents involving possible infostealer activity is the need to preserve evidence early.

Organizations sometimes rush immediately into:

wiping endpoints;
rebuilding machines;
or mass password resets.

While containment is important, preserving:

logs;
endpoint telemetry;
browser artifacts;
token history;
sign-in telemetry;
and authentication trails

is critical for understanding:

infection vectors;
lateral movement;
dwell time;
and post-compromise activity.

Responsible Disclosure Process

The findings described in this article were disclosed privately and in good faith under responsible disclosure principles.

The disclosure emphasized:

non-exploitation;
minimal disclosure;
avoidance of sensitive-data publication;
and coordinated remediation.

The organization acknowledged the report and initiated internal investigation and containment activities.

During the coordinated disclosure process, the organization assigned its CIO, Daniel Suraboyini, as part of the technical coordination and remediation communication process.

No public disclosure was performed during the initial remediation period.

Broader Industry Lessons

This case reflects broader trends increasingly affecting enterprises worldwide.

Modern enterprise security challenges are shifting away from traditional perimeter-only threats and toward:

identity compromise;
token theft;
cloud-session abuse;
authorization failures;
and trust-boundary weaknesses.

Organizations must increasingly prioritize:

secure-by-design architecture;
server-side authorization enforcement;
identity governance;
secure SDLC practices;
endpoint hygiene;
and modern session-management controls.

The most damaging failures are often not exotic zero-days.

They are fundamental trust-model mistakes.

Final Thoughts

Security is not merely a tooling problem.

It is fundamentally:

an architectural problem;
a governance problem;
and a trust-boundary problem.

As enterprises accelerate digital transformation initiatives around sustainability, compliance, ERP modernization, cloud identity integration, and business-platform consolidation, secure-design maturity becomes increasingly critical.

Responsible disclosure remains one of the most important mechanisms available for improving security outcomes while minimizing harm.

The goal of disclosure should never be humiliation.

The goal should be:

remediation;
accountability;
architectural improvement;
and stronger security maturity across the industry.

Reposted on:
Medium - https://medium.com/p/af7f9c24585c
Substack - https://trustboundarylab.substack.com/p/responsible-disclosure-case-study
Hashnode - https://trustboundarylab.hashnode.dev/client-side-authorization-enterprise-app-security