Why API security matters
If the frontend shows an error, the user can press refresh. But the API has direct access to the database, and a single vulnerability can expose the data of thousands of clients. That is why the API layer must have multi-layered protection: authentication, authorization, rate limiting, input validation and other controls.
In Sayt.uz practice REST and GraphQL APIs require different approaches. In REST every endpoint is protected separately, in GraphQL additional query depth and complexity controls are needed. In both cases the principles are the same โ treat every request as suspicious.
Rate limiting and abuse protection
Rate limiting limits the number of requests from a single user or IP in a given time. This protects against DDoS, brute force and resource exhaustion attacks. Token bucket and sliding window algorithms are most common. At Sayt.uz a Redis-based sliding window is implemented: a single IP must not exceed 100 requests per minute and 2000 per hour.
The login endpoint has a separate strict limit: 5 failed attempts per minute from one IP, then a 15-minute block. This protects against credential stuffing. For premium users the limit may be raised, but there must always be an absolute maximum.
API key management
An API key is not a simple password and must be protected separately. Each key should have a clear scope: read-only, read-write, admin and so on. Keys are never stored on the client side, only on the server via environment variable or secret manager.
In Sayt.uz practice each API key has an expiration date (usually 1 year) and mandatory rotation. The old key works together with the new one for 30 days, then is disabled automatically. Each key is logged separately and the owner receives an email when anomalies are detected.
Authentication types
Several authentication methods exist for APIs: Basic Auth, API key, OAuth 2.0, JWT, mTLS. Basic Auth is the simplest but sends login and password in every request โ use only over HTTPS. API keys are good for simple server-to-server integrations.
OAuth 2.0 and JWT are ideal for APIs with user context. mTLS (mutual TLS) gives the highest level of protection โ both server and client authenticate with certificates, used in finance and healthcare. At Sayt.uz JWT is used for public APIs and mTLS for partner integrations.
CORS and same-origin policy
CORS is a browser security mechanism that controls which domains can send requests to the API. A bad configuration of Access-Control-Allow-Origin: * allows data fetches from any site and increases CSRF risk.
The correct approach is a whitelist of specific domains. For APIs using credentials (cookies) wildcard origin is forbidden and a specific domain must be set. At Sayt.uz each environment (dev, staging, prod) has its own CORS rules and preflight cache is set to 24 hours.
Sayt.uz practice
API protection at Sayt.uz: all endpoints HTTPS only, JWT authentication, rate limits by IP and user, unique request_id per request, audit log for every modifying operation. Versioning via URL (/v1, /v2) and deprecation announced 6 months ahead. WAF (Web Application Firewall) is enabled through Cloudflare.