Thinking About Security in SPA, SSR, and APIs

The problem

Some web-security discussions treat everything as if it were the same system:

• SPA
• SSR
• API

As if changing where code runs did not also change:

• the attack surface
• credential exposure
• the trust boundary
• the risk of leaking data

It changes a lot.

Mental model

Think about it this way:

• SPA puts more logic and more interactive state in the browser
• SSR moves part of rendering and data access back to the server
• API defines the access boundary to the resource

None of those formats removes the need for the others.

But each one changes the main security question.

Breaking the problem down

In SPA, the browser is a more exposed surface

On the client, anything accessible to JavaScript deserves more care.

That especially affects:

• where the credential lives
• how much sensitive data goes down to the browser
• what the UI is allowed to assume

SPA is not “insecure by definition.”

But it demands more discipline around what really stays on the client.

In SSR, the server gains control over part of the flow

When the server builds the response, it can:

• read an HttpOnly cookie
• check session before rendering
• avoid sending unnecessary data to the client

That usually improves exposure control.

But it does not erase risk:

• the API still needs authorization
• sensitive data can still leak if it is serialized carelessly
• cache and CDN can still complicate authenticated content

In APIs, the resource boundary becomes explicit

The API is where the access decision needs to survive even without an interface.

If security depends on the frontend or SSR to work, the API is still weak.

The useful questions here are usually:

• who is making the request?
• which resource is being accessed?
• which action is being asked for?
• where did this data come from?

The central point is the trust boundary

Good security in these architectures does not start by memorizing stack.

It starts by asking:

• what lives in the browser?
• what stays on the server?
• what crosses the API?
• who can manipulate this value before it gets here?

Without that, teams only keep redistributing risk between layers.

Simple example

Compare three scenarios.

Pure SPA:

• the browser stores part of auth state
• the frontend calls the API directly

SSR:

• the server reads the credential and builds an authenticated page
• the browser receives fewer critical decisions ready-made

API:

• it still needs to validate access even when the request comes from a “trusted” frontend

If the backend accepts that “the frontend already filtered it,” the design failed.

If SSR serializes too much sensitive data to the client, the design failed in a different way.

It is not the same failure.

Common mistakes

• Thinking SSR makes authorization optional in the API.
• Treating the frontend as trusted just because your own team wrote it.
• Sending too much sensitive data down to the client for convenience.
• Discussing token storage without discussing the trust boundary.
• Using the same risk explanation for SPA and SSR as if they were the same thing.

How a senior thinks about it

People with more experience organize the problem by layer.

The reasoning usually sounds like:

What is exposed in the browser? What can the server validate before answering? And what does the API need to guarantee even if the client is compromised?

That way of thinking makes the conversation less religious and more architectural.

What the interviewer wants to see

In interviews, this topic measures design clarity.

The evaluator wants to see whether you:

• understand that risk changes with architecture
• separate browser, server, and API
• do not push authorization into the wrong layer
• connect storage, exposure, and trust boundary with real criteria

A strong answer often sounds like this:

In SPA I worry more about what stays accessible in the browser. In SSR I gain more control on the server, but the API still needs to authorize in the same way. The security design gets better when I clearly separate what is in the client, what the server knows, and what the API validates.

SPA, SSR, and API are not the same security conversation in different packaging.

When the layer changes, the risk surface changes with it.