How to protect an API or web app

Quick answer: Serve everything over HTTPS, authenticate with short-lived tokens or keys, rate-limit every endpoint at the web server (limit_req in Nginx), validate all input, hide admin routes from the public internet, and log enough to notice abuse. Most app breaches exploit missing basics, not exotic flaws.

Overview

APIs and web apps are attacked differently from servers: credential stuffing, token leaks, injection, scraping and Layer 7 floods all arrive as "valid" HTTP. Defense therefore lives in the web server and the application layer — the firewall alone cannot tell a login attempt from an attack.

Before you start

• An inventory of public endpoints and which of them mutate data or cost real resources.
• TLS already configured (SSL certificates guide).

Step-by-step guide

1. Rate-limit at Nginx:

   limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
   server {
       location /api/ { limit_req zone=api burst=20 nodelay; }
       location /login { limit_req zone=api burst=5; }
   }

2. Authentication hygiene: short-lived tokens, rotate API keys, never accept credentials over HTTP, store password hashes with bcrypt/argon2.
3. Input validation: parameterized SQL everywhere, strict schemas for JSON bodies, size limits (client_max_body_size).
4. Reduce exposure: bind admin panels and databases to localhost or a VPN; the firewall should show only 80/443 and SSH.
5. Consider a WAF: ModSecurity with the OWASP Core Rule Set for self-hosted filtering of common injection patterns.
6. Log and alert: 4xx/5xx spikes, auth failures and new user-agents; abuse you notice in an hour costs less than abuse you notice in a month.

Common issues

• Rate limits too strict: legitimate clients get 503s — set limits from observed traffic plus headroom, and use burst.
• Trusting client-side checks: validation must happen on the server; the client is attacker-controlled.
• Secrets in the repo: tokens committed to git history remain leaked forever — rotate and use environment variables.

When to contact support

Application security is customer territory, but if abuse escalates into traffic that affects the whole service, report it as an attack. For suspected data breaches on your side, isolate first (incident guide).

Frequently asked questions

What is the first thing to add to a public API?

Rate limiting at the web server level — Nginx limit_req with a per-IP zone stops credential stuffing, scraping and accidental client loops before they reach your application code.

Do I need a WAF for a small application?

It is a useful extra layer: ModSecurity with the OWASP Core Rule Set filters common injection and scanner patterns for free, though it never replaces input validation in the code.

How should API keys and tokens be handled?

Issue short-lived tokens where possible, rotate long-lived keys on a schedule, transmit them only over HTTPS, and keep them in environment variables — never in the git repository.

Related articles

• How to protect against brute-force attacks
• How to configure SSL certificates
• How to identify suspicious traffic
• What is a DDoS attack?

Need a hand? Contact Cloud2Y support →