← Insights·Infrastructure Security

API Security: Do Not Trust the Client

May 31, 2026·2 min read

API security with backend validation diagram. On the left, an untrusted client panel showing a browser UI with a hidden DELETE button, a disabled ROLE field, and the URL /api/tickets/42 with the 42 underlined as 'attacker changes this', plus four amber pills indicating client-side manipulation: changed ID, modified payload, direct API call, bypassed UI. Amber arrows representing manipulated requests flow into the right panel, a backend pipeline labeled THE REAL ENFORCER. The pipeline runs each request through six teal gates top to bottom: AUTH (is the user logged in?), AUTHORIZATION (can this user do this action?), OBJECT-LEVEL AUTHZ (can this user access this record?), INPUT VALIDATION (does this payload make sense?), RATE LIMIT (is this request too frequent?), LOG + MONITOR (should this be recorded?), exiting into an APPROVED REQUEST arrow, with a side branch from OBJECT-LEVEL AUTHZ to an amber 403 · DENIED pill, and a callout noting every request is treated as possibly manipulated. Below, a strip of seven equally weighted controls: backend-side validation, object-level authorization, input sanitization, rate limiting, clear error handling, logging plus monitoring, and abuse protection, with a small tag reading 'frontend helps · backend enforces'.

The frontend can hide buttons, disable fields, and guide the user through the right flow, but anything that comes from the client can be changed. Attackers swap IDs in URLs, edit payloads, call the API directly, and bypass the UI completely. Real security lives in the backend: authentication, authorization, object-level access checks, input validation, rate limits, and logging on every request, because every request is treated as possibly manipulated.

A common mistake in application security is trusting the client too much.

The frontend can improve the user experience, hide buttons, disable fields, and guide the user through the right flow. But it should never be treated as the security layer.

Anything that comes from the client can be changed.

A user can modify a request, call the API directly, change an ID in the URL, edit a payload, bypass the UI, or send values the frontend was never supposed to allow.

This is why real security must happen in the backend.

The backend should validate every request, check authentication, enforce authorization, and make sure the user is allowed to access the specific object they are asking for.

It is not enough to know that the user is logged in.

The backend must also ask:

Can this user access this specific record?
Can this user perform this specific action?
Does this value make sense?
Is this request too frequent?
Is the payload valid?
Should this action be logged?

For example, a user may be allowed to view their own ticket. But they should not be able to view someone else's ticket just by changing the ticket ID in the request.

Good API security should include backend-side validation, object-level authorization, input sanitization, rate limiting, clear error handling, logging, monitoring, and protection against abuse.

The client can help the user.

But the backend must enforce the rules.

A secure API assumes that every request can be manipulated and checks it before trusting it.

// related reading

Certificate expiration risk diagram. On the left, a CERTIFICATES EVERYWHERE panel showing ten services that quietly depend on a valid certificate, website, API, VPN, load balancer, mail, internal services, Kubernetes ingress, monitoring, identity, and integrations, with two services (WEBSITE and IDENTITY) flagged in amber as EXPIRES SOON, and a footer pill reading 'all depend on a valid cert'. On the right, an amber-bordered WHEN A CERT EXPIRES panel listing the immediate impact: users cannot log in, APIs fail, browser security warnings appear, automations break, integrations stop, customers lose access, with a footer note 'and all it took was a missed date'. Below, a CERTIFICATE LIFECYCLE strip with seven equally weighted controls: inventory, ownership, expiration monitoring, alerts, renewal process, automation, and post-renewal testing.

Infrastructure Security

Certificate Expiration Is Still Taking Systems Down

An expired certificate is one of the simplest, most preventable outages, and it still keeps happening. The fix is not heroics on renewal day. It is treating certificates like production assets: a real inventory, a clear owner, monitored expirations, alerts, a renewal process, automation where possible, and post-renewal testing so the change does not break something downstream.

Read article

GraphQL API security diagram. On the left, three clients (web, mobile, integration) each sending a differently shaped query. In the center, a single GraphQL endpoint with an inner schema view of User, Order, and Product types, ringed above by a chain of five security gates, AUTH, FIELD-LEVEL AUTHZ, QUERY DEPTH LIMIT, COMPLEXITY LIMIT, RATE LIMIT, and below by three operational pills: LOGGING · MONITORING · SCHEMA REVIEW. On the right, the data behind the schema as four cards: USERS, ORDERS, INVENTORY, and a SENSITIVE FIELDS card glowing amber with a connected RISK: OVER-EXPOSURE callout. Below, a GUARDRAILS strip listing seven equally weighted controls: clear permissions, field-level authorization, depth and complexity limits, rate limiting, logging, monitoring, and schema review.

Infrastructure Security

GraphQL: Powerful, Flexible, and Easy to Misuse

GraphQL gives clients a clean way to ask for exactly the data they need from a single endpoint. That same flexibility is also what makes it easy to over-expose. Without field-level authorization, query depth and complexity limits, rate limiting, logging, and a real schema review process, one badly shaped query can return information a user should never see, or quietly knock the backend over.

Read article

Back to all insights