Securing APIs: rate limits, CORS and input checks

An API is a door that anyone on the internet can knock on, including scripts that never use your website. This tutorial hardens a small Brew & Bean FastAPI service with three of the most useful defences: rate limiting (slow down abuse), CORS (decide which websites may call your API from a browser) and input checks (never trust what the client sends). You will also learn what CORS does not do, a common misunderstanding.

Prerequisites: Python 3.10 or newer and basic FastAPI knowledge (see *Build an API with Python and FastAPI* in Backend Development). Broader API risks are in *API security essentials* in Backend Development; here we focus on hands-on code. Run everything on your own machine.

mkdir bb-secure-api
cd bb-secure-api
python -m venv .venv
# Windows: .venv\Scripts\activate     macOS/Linux: source .venv/bin/activate
pip install fastapi uvicorn slowapi

Creates a virtual environment and installs FastAPI, the Uvicorn server and slowapi, a rate-limiting library for Starlette and FastAPI.

Save this as main.py. Read the comments: each numbered section is explained below the code.

from typing import Literal

from fastapi import FastAPI, Request
from fastapi.middleware.cors import CORSMiddleware
from pydantic import BaseModel, ConfigDict, Field
from slowapi import Limiter, _rate_limit_exceeded_handler
from slowapi.errors import RateLimitExceeded
from slowapi.util import get_remote_address

app = FastAPI()

# ---- 1. Rate limiting -------------------------------------------------
limiter = Limiter(key_func=get_remote_address)
app.state.limiter = limiter
app.add_exception_handler(RateLimitExceeded, _rate_limit_exceeded_handler)

# ---- 2. CORS: only our own website may call this API from a browser ----
app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:5173"],  # replace with your real site in production
    allow_methods=["GET", "POST", "PATCH"],
    allow_headers=["Content-Type"],
)

# ---- 3. Input checks: the server decides what is valid ----------------
MENU = {
    "espresso": 120, "cappuccino": 180, "cold-brew": 220, "filter-coffee": 80,
    "masala-chai": 90, "croissant": 150, "banana-bread": 130, "veg-sandwich": 160,
}
ItemId = Literal[
    "espresso", "cappuccino", "cold-brew", "filter-coffee",
    "masala-chai", "croissant", "banana-bread", "veg-sandwich",
]


class OrderItem(BaseModel):
    model_config = ConfigDict(extra="forbid")  # reject unknown fields
    item_id: ItemId
    qty: int = Field(ge=1, le=20)


class OrderIn(BaseModel):
    model_config = ConfigDict(extra="forbid")
    customer_name: str = Field(min_length=1, max_length=60)
    phone: str = Field(pattern=r"^[6-9][0-9]{9}$")  # 10-digit Indian mobile number
    items: list[OrderItem] = Field(min_length=1, max_length=20)


@app.get("/menu")
@limiter.limit("60/minute")
def get_menu(request: Request):
    return [{"id": k, "price": v} for k, v in MENU.items()]


@app.post("/orders", status_code=201)
@limiter.limit("5/minute")
def create_order(request: Request, order: OrderIn):
    # The price comes from OUR menu, never from the client.
    total = sum(MENU[i.item_id] * i.qty for i in order.items)
    return {"status": "received", "total": total}

A menu endpoint and an order endpoint with rate limits, a CORS allowlist and strict validation. The server computes the total from its own price list.

uvicorn main:app --reload

Starts the API at http://127.0.0.1:8000. Interactive docs are at /docs.

Rate limiting means "at most N requests per time window from one client". It protects you from:

- Brute-force guessing of passwords or codes. - Scraping your whole menu or customer data. - Cost and denial of service: a loop of requests that exhausts your server, database or paid AI API.

In the code, get_remote_address identifies a client by IP address, and @limiter.limit("5/minute") allows five order requests per minute per IP. The 6th gets HTTP 429 Too Many Requests. Note that slowapi needs a parameter named request: Request on each limited endpoint.

Choose limits by endpoint risk: a login or OTP endpoint needs a strict limit (for example 5 per minute), a public menu can allow far more. Per-user limits (using the logged-in user's id as the key) are fairer than per-IP limits because many students share one college or mobile-network IP.

Browsers enforce the same-origin policy: JavaScript on https://evil.example cannot read responses from https://api.brewandbean.example unless the API says that is allowed. An origin is scheme + host + port, so http://localhost:5173 and http://localhost:3000 are different origins.

CORS (Cross-Origin Resource Sharing) is how your API tells the browser which origins may read its responses, using headers such as Access-Control-Allow-Origin. In the code, only http://localhost:5173 (the default Vite dev server) is allowed.

A typical beginner problem: the browser shows "blocked by CORS policy" during development. The fix is to add your frontend's exact origin to the allowlist (check the port!), not to set * everywhere. Remember that the error comes from the browser, so the request may still have reached your server.

Anything from outside your server is untrusted: JSON bodies, query strings, headers, file uploads. The rule is validate on the server, with an allowlist: define what is acceptable and reject everything else, instead of trying to list bad things.

In the code:

- item_id is a Literal of real menu ids, so "banana" is rejected. - qty must be 1 to 20. Without a limit, someone could order 999999999 espressos or send a negative quantity to get a negative total. - phone must match a 10-digit Indian mobile pattern. - Strings have a max_length, and lists have a max_length, to avoid huge payloads. - extra="forbid" rejects unknown fields, so a client cannot sneak in a total or is_admin field. - The total is computed from the server's MENU. Never accept a price from the client.

Validation on the frontend is for user experience only; attackers do not use your frontend. Validation also does not replace safe handling later: still use parameterised SQL queries and output escaping (see *Injection attacks: SQL, command and XSS*).

# 1. A valid order works
curl -i -X POST http://127.0.0.1:8000/orders \
  -H "Content-Type: application/json" \
  -d '{"customer_name":"Asha","phone":"9876543210","items":[{"item_id":"cappuccino","qty":2}]}'

# 2. A bad order is rejected: invalid item, negative qty, extra field
curl -i -X POST http://127.0.0.1:8000/orders \
  -H "Content-Type: application/json" \
  -d '{"customer_name":"Asha","phone":"9876543210","total":1,"items":[{"item_id":"gold","qty":-5}]}'

Use Git Bash, macOS or Linux. On Windows PowerShell, use curl.exe and write the JSON with escaped quotes, or use the /docs page instead.

Now test the rate limit. Send the valid order six times quickly and watch the last one fail. Bash makes this easy:

for i in 1 2 3 4 5 6; do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST http://127.0.0.1:8000/orders \
    -H "Content-Type: application/json" \
    -d '{"customer_name":"Asha","phone":"9876543210","items":[{"item_id":"espresso","qty":1}]}'
done

Prints the HTTP status of each request.

Act as an application security reviewer. Below is my [FastAPI / Express] endpoint code. Review it for: missing authentication or authorisation, missing input validation and size limits, unsafe CORS, missing rate limits, information leaks in errors, and trusting client-supplied values (such as prices or user ids). For each issue give: where it is, how it could be abused in plain words, and a small code fix. Do not invent issues; if something is fine, say so.

<code>
[paste your code here]
</code>

What to expect: Check each suggestion yourself and test the fix. Never paste real secrets into an AI tool.