Single page applications shifted the centre of gravity from the server to the browser. The user experience improved, the front end teams cheered and the security model quietly changed in ways many organisations have still not caught up with. The result is a generation of SPAs that look modern, feel modern and yet carry vulnerability classes that traditional web testing methodologies were not built to find.
Client-Side Logic Is Public By Default
Every business rule that lives in your front end JavaScript is visible to anyone with the developer tools open. That includes price calculations, role checks and validation logic. SPAs encourage teams to push more decision making into the browser, which is fine for usability but disastrous when the corresponding server side checks are missing. The classic finding is a hidden admin route that the front end never shows but the API happily serves.
Authentication Tokens Need Careful Handling
Storing JWTs in local storage feels convenient until you remember that any successful XSS payload then has full account access. HttpOnly cookies remove that attack surface but introduce CSRF considerations. There is no perfect answer, only trade-offs that need to be made deliberately. The teams that get this right document the choice, review it during architectural changes and confirm it with a penetration testing quote that includes scoped front end testing.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
Most of the serious SPA findings we report come down to assumptions in the front end that the API does not enforce. The fix is rarely glamorous. Mirror every meaningful access check on the server, treat the browser as untrusted, and run focused tests against the API rather than the UI.
Testing SPAs Requires A Different Mindset
Burp Suite with the right configuration handles SPAs well, but the default proxy approach often misses the interesting traffic because SPAs make many small API calls that the tester never sees in their entirety. Pair the proxy with manual exploration of the application using developer tools, paying attention to the JavaScript bundle for hidden routes and the localStorage and IndexedDB stores for cached sensitive data. The interesting findings tend to come from the parts of the SPA that the UI does not actively expose during normal use. Mobile applications that wrap a web view share many of the SPA characteristics and deserve the same testing treatment. The wrapper does not improve security and frequently introduces additional considerations around the bridge between the native code and the web content.
Build Pipelines Add Their Own Risks
A modern SPA pulls in hundreds of npm packages, often without anyone reviewing the dependency tree in detail. Supply chain attacks targeting popular packages have moved from theoretical to routine. Lock down your dependency versions, monitor for known vulnerable transitive packages and review your build configuration for obvious mistakes. Source maps in production, for example, hand attackers a tidy roadmap of your application logic.
A focused web application pen testing engagement on a SPA looks different from a traditional web test. Make sure your provider knows the difference before you commit. The SPAs that survive contact with real attackers tend to be the ones where the development team took security seriously from the architectural stage onwards. Web application security is a discipline that rewards patient investment. The teams that treat it as ongoing work consistently outperform the ones that treat it as a project with an end date.
