What should teams do first when adding security testing for single page applications?

The first step is to choose a security testing tool that is fully capable of API security testing, then configure it with the application’s API routes. OpenAPI, GraphQL introspection, and WSDL are common inputs. Once the scanner can reach the APIs, teams can run a baseline scan and automate future checks in CI/CD.

Start With API Coverage, Not the Browser Layer

Single page applications often look like a browser security problem, but the first meaningful testing step is usually to verify the API surface the front end depends on. If the scanner cannot discover or reach the application’s routes, the test will miss the behaviour that actually carries authentication, authorisation, and data flow. That is why route discovery, schema ingestion, and baseline reachability matter before any ongoing automation.

For teams doing this for the first time, the practical aim is not broad “website scanning” but dependable API visibility across the paths the SPA calls. OpenAPI documents, GraphQL introspection, and WSDL all help a tool understand what to test, but only if the configuration reflects the real traffic path the application uses. NIST’s control families on configuration management and system monitoring are a useful reference point for treating test coverage as an operational control, not an ad hoc task. NIST SP 800-53 Rev 5 Security and Privacy Controls

In practice, many teams discover weak test coverage only after an API change has already bypassed their initial scanner configuration, rather than through intentional route discovery.

How API-First Testing Fits a Single Page Application

A single page application shifts most meaningful security behaviour into API requests, even when the user experience appears to be entirely client-side. The browser code may control rendering and navigation, but the API controls identity assertions, state changes, and data retrieval. That means the security test must understand the request paths, methods, parameters, and schemas that the front end actually uses. If the scanner is only pointed at the page URL, it may find static content, but it will not meaningfully exercise the endpoints where broken authorisation, injection, or excessive data exposure appear.

The first operational decision is to feed the tool structured discovery data. OpenAPI is often the cleanest starting point because it gives the scanner a route map and request model. GraphQL introspection can do the same for GraphQL services, while WSDL remains relevant where legacy SOAP back ends still support the SPA. If no machine-readable contract exists, teams usually need to capture traffic or export routes from the gateway so the scanner has enough context to reach authenticated and parameterised endpoints. Without that setup, baseline scans tend to under-report risk or produce misleadingly shallow findings.

Use the route inventory that best reflects live API behaviour, not just documentation that has drifted.
Confirm that authentication, session handling, and test credentials allow the scanner to reach protected operations.
Check that the scanner can exercise both read and state-changing endpoints, not only public GET requests.
Run a baseline scan before automation so you can judge whether coverage is complete enough to trust the CI/CD signal.

Automating the scan in CI/CD is valuable only after the discovery step is stable, because repeatable automation will also repeat any blind spot. This guidance breaks down when the SPA has no reliable API contract, when route discovery is incomplete, or when authentication flows prevent the tool from reaching the real attack surface.

When the Usual SPA Testing Pattern Breaks Down

Tighter API-driven testing often increases setup overhead, requiring teams to balance deeper endpoint coverage against the time needed to maintain route definitions and test access. That tradeoff becomes more visible in SPAs with dynamic APIs, multiple back ends, or frequently changing schemas.

One edge case is a SPA that uses several services behind a gateway, where a single scan profile no longer represents the whole application. In that situation, the first step is still API discovery, but the team may need separate profiles for different domains, tenants, or auth contexts. Another edge case is a GraphQL or REST hybrid, where one discovery source is not enough to model the surface accurately. Guidance differs from consensus here: some teams prefer to start with passive traffic capture, while others prefer contract-first onboarding. Both approaches can work, but only if they produce a testable endpoint inventory rather than a general idea of the app.

For highly dynamic front ends, the main failure mode is not scanner weakness but stale configuration. If route changes are frequent and not versioned, security testing becomes a lagging indicator instead of a reliable control.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	16 — Application Software Security	SPA testing hinges on validating app and API attack surface coverage.
	8 — Audit Log Management	Baseline scans and CI/CD checks support repeatable validation and monitoring.
Recommendation — Map SPA endpoints into security testing and verify coverage of exposed application interfaces. Retain scan evidence and monitor CI/CD results for drift in API security coverage.
NIST CSF 2.0	PR.DS — Data Security	API testing targets exposed data paths and protected information handling.
	DE.CM — Continuous Monitoring	Automated rescan in CI/CD is a monitoring practice for changing SPA interfaces.
Recommendation — Protect API-exposed data flows by testing the routes that carry sensitive application data. Continuously monitor API changes and rescan when routes or schemas change.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	SPA APIs are public-facing application attack surfaces that require validation.
Recommendation — Test public API endpoints for exposure paths an attacker could abuse.

Practitioner Guidance

What to prioritise: Treat API reachability as the gate for SPA security testing. If the tool cannot authenticate, enumerate, and exercise the actual endpoints, any later automation will mostly measure the scanner’s blind spots rather than application risk.

What to verify: Confirm that the chosen tool can handle the application’s real access pattern, including the discovery source, session state, and any state-changing operations that matter to the business. The useful question is whether the baseline scan would cover the routes that an attacker or tester would actually target, not whether the page loads successfully.

Common mistake: Teams often start with front-end crawling and assume that is enough for a SPA. It is not, because the security-relevant behaviour usually lives in the API layer, where authentication, object access, and input handling are enforced.

Practitioner takeaway: The first good decision is to make the scanner speak the application’s API language before asking it to report on security, because coverage quality determines whether automation becomes a control or a false sense of assurance.