Single Page Application Testing

This is the mistake we see most. A team ships a beautiful Angular app that hides the admin panel from ordinary users, and assumes the job is done. It is not. The browser is fully under the user’s control. Anyone can read the bundle, see every route and API call, forge requests in Burp Suite, and ask the server for whatever they want. If the API does not check who is asking on every single call, the SPA is wide open, no matter how careful the front end looks.

Behind every SPA is a REST or GraphQL API, and that is where we spend most of the time. We enumerate every endpoint the app calls, then test each one for missing authorization, object-level access flaws and mass-assignment. A single endpoint that returns another user’s data when you change one number in the request is often the whole finding.

We proxy the application through Burp Suite and exercise every feature, capturing each REST call and GraphQL operation. We read the JavaScript bundle and source maps for routes, feature flags, hidden admin functions and, more often than teams expect, hardcoded keys or internal URLs that were never meant to ship to the browser.

With a full map of the API, we test access control the only way that proves anything: with multiple accounts. We take a low-privilege user’s session and try to reach a higher-privilege user’s data and a higher-privilege user’s actions.

Horizontal access: IDOR

We change identifiers in requests to reach records that belong to other users or other tenants. In SPAs this is common, because the front end only ever requests the current user’s ID and the developers assumed nobody would ask for another.

Vertical access: privilege escalation

We call admin-only endpoints from an ordinary account. If the API decides what you can do based on a role claim in a token you can tamper with, or worse, based only on which button the front end showed you, escalation follows quickly.

SPAs usually authenticate with tokens, and where those tokens live matters. A JWT in localStorage is readable by any script on the page, which turns any XSS into full account takeover. We test how tokens are stored, whether they expire and rotate, how refresh flows behave, and whether the app is vulnerable to DOM-based XSS through framework sinks like dangerouslySetInnerHTML or unsanitised template binding.

The signature SPA vulnerability. The API exposes granular endpoints and trusts the ID in the request. We enumerate objects and confirm whether one user can read or modify another’s, then show the exact request that does it.

Where the API is GraphQL, we check whether introspection is exposed, whether deep nested queries can exhaust the server, whether aliasing bypasses rate limits, and whether each mutation independently verifies ownership. A single unguarded mutation can undo an otherwise careful schema.

A permissive CORS policy that reflects the origin and allows credentials lets a malicious site read your authenticated API responses in a victim’s browser. We test the policy against real attacker origins rather than trusting the config file.

Front-end code ships to everyone. We comb the JavaScript for API keys, third-party tokens, internal hostnames and debug endpoints. It is remarkable how often a paid third-party service key ends up sitting in a public bundle.

A short, non-technical read: the overall risk, the issues that need attention now, and what they would mean if exploited against your users.

Each finding comes with the affected endpoint, a CVSS score, business impact, the exact request and response, step-by-step reproduction, and a specific fix. Where the flaw is client-side, we say so; where it is the API failing to enforce a rule, we say that too, so nobody fixes the wrong layer.

After your team ships the fixes, we re-test every finding at no extra cost and update the report to reflect what is genuinely closed.

We map findings to the OWASP Top 10 and, because the API carries the risk, the OWASP API Security Top 10, which is written precisely for the broken-authorization problems SPAs create.

The report and attestation letter are built to support ISO 27001, SOC 2, PCI DSS requirement 11 and GDPR obligations around protecting personal data. Tell us your framework and we align the deliverables so the test counts as evidence.

Each has its own unsafe rendering paths. React has dangerouslySetInnerHTML, Angular has bypassSecurityTrust and template injection, Vue has v-html. We know where each framework lets untrusted data reach the DOM, and we test those paths directly rather than fuzzing blindly.

Many SPAs share their API with a mobile app. That is worth flagging, because a broken authorization check does not care which client sends the request. When we find an IDOR in the API your web front end uses, the same flaw is usually reachable from the phone in every customer’s pocket, which raises the real-world impact of the finding.

Next.js, Nuxt and similar frameworks blur the line between client and server. We check whether server-rendered payloads leak fields the UI intends to mask, and whether data-fetching functions enforce the same authorization the client-side routes assume.