Backend Security: Knowing Where Trust Ends

In backend engineering, one idea sits underneath almost every security decision:
the trust boundary.

The frontend, whether it’s a web app, a mobile app, or a third-party script, runs in an environment you do not control. Anyone can modify it. Anyone can replay requests. Anyone can send inputs your UI never intended.

Because of that, everything that crosses the network into your backend must be treated as untrusted. Security is the process of validating, constraining, and carefully accepting that input before it is allowed anywhere near business logic or data.

Identity and Access: The AuthN/AuthZ Distinction

Every request forces the backend to answer two questions:

Who is making this request?
What are they allowed to do?

Authentication answers the first.
Authorization answers the second.

A common failure is doing the first correctly and being careless with the second.

A user may be logged in, but that does not mean they should be allowed to access every resource. Changing a user_id or order_id in a URL should never be enough to see someone else’s data.

If a request to /api/orders/5501 succeeds for a user who only owns order 5502, the system has an authorization failure. This class of bug is known as Broken Object Level Authorization (BOLA), or IDOR.

The fix is not frontend checks.
The fix is scoping access at the data query level, using the authenticated user’s identity as part of the query itself.

Hardening the Ingestion Layer

We defend the system by implementing multiple layers of protection against known attack vectors.

1. Input Validation and Parameterised Queries

The most dangerous thing a backend can do is execute a string provided by a user.

• The Vector: SQL Injection (SQLi) occurs when user input is concatenated directly into a query.

• The Defence: Use Parameterised Queries (Prepared Statements). This ensures the database treats the input as literal data, not executable code.

2. Secure Token Management (JWTs and Sessions)

If you use JSON Web Tokens (JWTs) for authentication, the implementation details matter.

• The Risk: Storing sensitive data in the payload (which is only encoded, not encrypted) or failing to verify the signature on the backend.

• The Defense: Always use strong signing algorithms (like RS256) and ensure tokens are transmitted over HTTPS with HttpOnly and Secure cookie flags to prevent XSS-based theft.

3. Protecting Resources: Rate Limiting

A backend that is always available is a backend that can be brute-forced or DDOSed.

• The Vector: Resource exhaustion or credential stuffing.

• The Defense: Implement Rate Limiting at the gateway or application level. Use a "Leaky Bucket" or "Token Bucket" algorithm to restrict how many requests a single IP or User ID can make in a given timeframe.

The Principle of Least Privilege

Why do we go through this effort? Because software is complex, and bugs are inevitable. The goal of security is Defence in Depth.

We apply the Principle of Least Privilege: every service, every database user, and every human operator should only have the minimum level of access required to perform their job.

• If your API only needs to read from the database, its database user should not have DELETE or DROP permissions.

• If one microservice is compromised, least privilege ensures the attacker cannot use those credentials to pivot and destroy the entire infrastructure.

Engineering Trade-offs

Security often comes at the cost of performance or developer experience.

• Encryption at rest adds CPU overhead.

• Strict CORS policies can make local development frustrating.

• Frequent token rotation adds complexity to the frontend.

A backend engineer understand that security is a risk management exercise. You don't build a vault to protect a sandwich; you build security that is proportional to the value of the data and the severity of the threat model.

Security Checklist for the PR Review:

• [ ] Parameterised Queries: Are all DB calls using prepared statements?

• [ ] AuthZ at the Resource Level: Is the user_id from the token being used to scope the query?

• [ ] Fail-Fast Validation: Are we rejecting malformed input before it hits the logic layer?

• [ ] Credential Isolation: Are all secrets pulled from environment variables/vaults?

What Comes Next

Next, we should talk about Scaling and Performance Engineering. We'll analyze how to identify bottlenecks and the trade-offs between vertical and horizontal scaling.

This article is part of the Thinking in Backend series, where we focus not just on what systems do, but how and why they behave the way they do.