Security in System Design: Authentication, Authorization, Encryption and Abuse Prevention

A developer notices that the URL for their own order is /api/orders/1043. Out of curiosity they try /api/orders/1042, and see a stranger's name, address and purchases. The API checked that the caller was logged in. It never checked that order 1042 belonged to them. This flaw is so common that OWASP lists it first among API security risks.

Security in system design is not about memorising attacks. It is about a small set of architectural decisions (who can call what, how identity is proven and carried, where secrets live, what is encrypted, what is logged) made deliberately and checked at every boundary. This article covers those decisions at the depth an SDE-2 interview expects. It is not a penetration-testing course.

• Security principles that shape architecture: trust boundaries, least privilege, defence in depth.
• Authentication: passwords, multi-factor authentication and identity providers.
• Sessions versus tokens, and how to use JWTs safely.
• Authorisation: roles, attributes and per-object checks, and the OWASP API Top 10.
• Service-to-service identity and zero trust.
• Encryption in transit and at rest, and secrets management.
• Input validation, abuse prevention and SSRF.
• Privacy, audit logs and payment data.

• Trust boundaries: draw where data crosses from less trusted to more trusted zones (internet to gateway, gateway to service, service to database, your system to a third party). Every boundary validates input and authenticates the caller.
• Least privilege: every user, service and credential gets only the permissions it needs. A thumbnail worker needs to read uploads and write thumbnails, not to delete accounts.
• Defence in depth: assume any one control can fail; layer them (edge filtering, authentication, per-object authorisation, encryption, monitoring).
• Secure defaults: private by default (buckets, APIs, new features), deny by default for authorisation.
• Minimise the attack surface: fewer exposed endpoints, ports, admin paths and stored secrets.

A simple threat-modelling habit in interviews: for each main flow, ask what an attacker would want (data, money, disruption), where they could enter, and what stops them.

Authentication (authn) establishes identity. Authorisation (authz) decides permissions. They are different questions, answered by different code, and confusing them causes the opening bug.

• Store only a slow, salted hash, never the password or a fast hash. OWASP's password-storage guidance recommends algorithms designed for this purpose, such as Argon2id, scrypt or bcrypt (and PBKDF2 where required), with appropriate work factors (Password Storage Cheat Sheet).
• Rate-limit login attempts per account and per source, and watch for credential stuffing (attackers trying leaked passwords from other sites).
• Offer multi-factor authentication (an authenticator app, a passkey or hardware key, or less preferably SMS) for anything valuable.
• For authenticator and assurance-level requirements, NIST's Special Publication 800-63B-4 (published in 2025) is the reference many organisations follow (NIST SP 800-63B-4).

Building authentication well is hard. Many systems delegate it to an identity provider (a managed service, a company directory, or "sign in with" a large provider) using standard protocols:

• OAuth 2.0 is an authorisation framework that lets an application obtain limited access to a resource on a user's behalf, using access tokens (RFC 6749). Its current security best practice is RFC 9700 (OAuth 2.0 Security Best Current Practice).
• OpenID Connect adds an identity layer on top of OAuth 2.0, so the application learns who the user is through an ID token (How OpenID Connect works).

In a design, you can say: "users authenticate with our identity provider via OpenID Connect; the API gateway validates access tokens; services trust the gateway-validated identity and check authorisation themselves."

After login, every request must carry proof of identity. Two families:

The server creates a random session id, stores session data server-side (for example in Redis, so any stateless app server can read it, article 08), and sends the id in a cookie.

• Revocation is easy: delete the session; the user is logged out everywhere immediately.
• Every request needs a lookup in the session store.
• Cookies should be marked Secure (HTTPS only), HttpOnly (not readable by page scripts) and given an appropriate SameSite policy; OWASP's session-management guidance covers these and other session controls (Session Management Cheat Sheet).

A JSON Web Token carries claims (user id, expiry, scopes) and a signature, encoded as three base64url parts separated by dots: header, payload and signature (RFC 7519). Any service with the verification key can check it without a lookup.

• No per-request lookup: good for many services and high request rates.
• Hard to revoke: a stolen token is valid until it expires.
• Signed, not encrypted by default: anyone holding it can read the claims. Do not put secrets in it.

Rules for using JWTs safely, in the spirit of the JWT best-current-practice document (RFC 8725):

• Verify the signature with the expected algorithm only; never accept none or let the token choose the algorithm.
• Check the claims: issuer (iss), audience (aud, so a token for one service is not accepted by another), expiry (exp), and not-before (nbf).
• Short lifetimes for access tokens (minutes), with refresh tokens (longer-lived, stored securely, rotated on use) to get new ones.
• For immediate revocation needs (account compromise, logout everywhere), keep a small denylist of revoked token ids until they expire, or use sessions.

// Illustration: what token validation must check (library calls vary).Claims claims = verifier        .requireAlgorithm("RS256")              // never trust the token's own choice        .requireIssuer("https://auth.pixly.example")        .requireAudience("pixly-api")        .clockSkewSeconds(30)        .verify(bearerToken);                    // signature + exp + nbfif (revokedTokenIds.contains(claims.id())) {    throw new Unauthorized();}

A common hybrid: the browser holds a session cookie with the gateway (easy revocation), and the gateway issues short-lived internal tokens to services.

Authorisation must answer, for every request: may this identity perform this action on this specific resource?

• Role-based (RBAC): permissions attached to roles (admin, editor, viewer). Simple; coarse.
• Attribute-based (ABAC): decisions from attributes of the user, resource and context (department, owner, time, region). Flexible; more complex.
• Relationship-based: permissions from relationships (owner, follower, team member), natural for social and collaboration products.

OWASP's authorisation guidance stresses principles such as least privilege, deny by default, validating permissions on every request, and checking access at the object level (Authorization Cheat Sheet). In architecture terms:

1. Check per object, in the service that owns it: "is order 1042 owned by this user, or is the user staff with permission?" The gateway can check "is this a valid user"; only the order service knows who owns order 1042.
2. Never trust ids from the client alone: derive the user from the authenticated token, not from a user_id in the request body.
3. Check functions: admin endpoints require admin permissions, verified server-side.
4. Check properties: do not let clients set fields they should not (a user updating their own role through a generic update endpoint).
5. Centralise policy logic in a library or policy service so it is consistent, but enforce it where the data lives.

// Illustration: object-level authorisation in the owning service.Order order = orders.findById(orderId).orElseThrow(NotFound::new);if (order.customerId() != caller.userId() && !caller.hasPermission("orders:read:any")) {    throw new NotFound();   // 404 rather than 403, so ids of others' orders are not confirmed}

OWASP's list of the most critical API risks is a useful checklist for any design review (OWASP API Security Top 10 2023):

Inside the system, services call each other. "It is on the internal network, so it is trusted" is the assumption zero trust rejects: NIST's zero-trust architecture guidance describes moving away from implicit trust based on network location towards authenticating and authorising each request (NIST SP 800-207).

• Mutual TLS (mTLS): both sides present certificates, so each service proves its identity and traffic is encrypted. Service meshes can automate this (article 26).
• Workload identities and short-lived credentials instead of long-lived shared passwords.
• Least privilege between services: the notification service may read contact details, not payment data.
• Propagate the end user's identity (for example as a signed internal token) when a downstream service must authorise on the user's behalf.

• In transit: TLS everywhere users connect, and for internal traffic carrying sensitive data (article 03 discussed termination at the load balancer and re-encryption). TLS 1.3 is the current version.
• At rest: enable encryption for databases, disks, backups and object storage. Managed key management services hold keys and support envelope encryption (data is encrypted with a data key, which is itself encrypted by a master key the service guards), rotation and access logging.
• Field-level encryption for especially sensitive fields (government ids, bank details), so even database administrators and backups do not expose them in plain text.
• Hashing is not encryption: passwords are hashed (one-way); data you need to read back is encrypted.

Encryption at rest protects against stolen disks and backups; it does not protect against an attacker who can query your application. Authorisation does that.

Database passwords, API keys, signing keys and provider credentials are secrets. OWASP's secrets-management guidance covers the essentials: centralise secrets, control and audit access, rotate them, and avoid exposing them in code, logs and build artefacts (Secrets Management Cheat Sheet).

• Never in source code, container images, client apps or logs.
• Store them in a secrets manager (a managed cloud service or a self-hosted vault), fetched at startup or runtime with the service's identity.
• Rotate regularly and immediately after suspected exposure; design so rotation needs no downtime (support two valid credentials during the switch).
• Scan repositories for accidentally committed secrets.
• Configuration that is not secret can live in environment variables or config files, as the Twelve-Factor guidance suggests for configuration in general; secrets deserve the stronger handling above.

• Validate at the boundary (article 04): types, lengths, ranges, formats; reject early.
• Parameterised queries against SQL injection; output encoding against cross-site scripting in web pages.
• Limits on everything: request size, upload size, page size, query complexity, number of items per batch.
• Rate limits and quotas per user, API key and IP (article 31), plus stricter limits on sensitive flows (login, password reset, sign-up, OTP verification).
• Bot and fraud controls on business flows attackers abuse: ticket purchases, coupon redemption, fake sign-ups.
• Edge protection: a CDN or web application firewall absorbs volumetric attacks and filters known bad patterns before they reach your servers.
• CORS configured narrowly for browser clients; it controls which web origins may call your API from a browser, not who may call it at all.

Any feature where your server fetches a URL supplied by a user (link previews, "import from URL", webhooks you call) can be abused to make your server request internal addresses: cloud metadata endpoints, admin panels, internal services. OWASP's SSRF prevention guidance recommends approaches such as allow-listing destinations where possible, validating and resolving addresses and blocking private and link-local ranges, disabling redirects or re-validating after them, and isolating the fetching component (SSRF Prevention Cheat Sheet). In a design, run URL fetching in an isolated worker with no access to internal networks.

• Collect less: do not store data you do not need. Data you do not hold cannot leak.
• Know where personal data lives: classify fields and stores, including logs, caches, analytics, events and backups.
• Retention and deletion: define how long each kind of data is kept, and how a user's data is deleted or anonymised everywhere, including derived stores. Event-sourced and log-based systems need special techniques (article 27).
• Access control and logging for personal data, especially by staff.
• Residency: some regulations require certain data to stay in a country or region, which shapes multi-region design (article 24).
• Regulation: laws such as the EU's GDPR and India's Digital Personal Data Protection Act, 2023 impose obligations on how personal data is collected, used, stored and erased. Requirements and rules change; confirm current obligations with official sources and legal advice for your situation.

An audit log records security-relevant actions: logins and failures, permission changes, admin actions, data exports, access to sensitive records, configuration changes. It answers "who did what, when, from where".

• Separate from application debug logs, with stricter access and longer retention.
• Append-only and tamper-evident (write-once storage, hash chaining or a separate account).
• Contains identities and actions, not secrets or unnecessary personal data.
• Monitored: alerts on suspicious patterns (mass exports, repeated failures, privilege escalations).

The Payment Card Industry Data Security Standard (PCI DSS, currently version 4.x) applies to entities that store, process or transmit cardholder data (PCI DSS). The architectural lesson: avoid touching card data at all where you can. Use a payment provider's hosted payment page or client-side fields that send card details directly to the provider, and store only the provider's tokens and payment references. This greatly reduces the parts of your system in scope for card-security requirements. Article 39 builds on this.

• Checking authentication but not per-object authorisation.
• Trusting a user id sent in the request body.
• Long-lived JWTs with no revocation strategy; accepting tokens without checking audience and issuer.
• Secrets in code, environment files in repositories, or logs.
• Treating the internal network as trusted.
• Fetching user-supplied URLs from servers with internal access.
• Storing card numbers instead of provider tokens.

• In the Harden phase, cover: authentication method, token or session choice, object-level authorisation, encryption in transit and at rest, secrets, rate limiting, and one abuse case specific to the problem.
• Use precise words: "authn at the gateway; authz per object in the owning service".
• Mention privacy and audit logging when personal or financial data is involved.
• For payments, say "we never store card data; we use the provider's tokens".

GET    /api/users/{userId}/messages        (requires a valid token)PATCH  /api/users/{userId}  body: {"name": "...", "role": "..."}DELETE /api/admin/users/{userId}           (hidden from the app's menu)GET    /api/export?format=csv              (returns all orders)

• Next: The System Design Interview Framework: A Repeatable Method for Any Problem begins the case studies, where every design includes a security section built from this article.
• Later: the rate limiter (article 31) and the payment system (article 39) go deeper on two topics introduced here.