Security in action
What happens when someone floods your site with requests: the first ones go through and the rest get stopped.
Live. Uses the AIM API.
What your client sees
A real-life example: Picture a clinic's appointment form. A bot keeps sending fake messages: after a few, the site stops it, and patients keep writing with no trouble.
Under the hood
What it does, in technical terms
Send 15 requests in a row to the API and watch the rate limit let 10 through and stop the rest with a 429, then check the real security headers that protect this site.
- Technologies
- Hono
- Postgres
- Drizzle
- Preact
- Backed by
Architecture
1.Your browser
It sends the 15 requests in order and reads from each response the status and the RateLimit and Retry-After headers.
2.AIM's API on Cloudflare (Hono)
It counts each visitor's requests with a hash of their IP, never the IP, and groups IPv6 by /64 network.
3.Postgres on Neon (Drizzle)
It keeps count in a one-minute sliding window. Past the limit, the API answers 429 with Retry-After.
4.The site's headers
HSTS, X-Frame-Options, Permissions-Policy and the rest come with every page. The CSP goes in a meta tag, with hashes.
By the numbers
- requests per minute per connection
- 10
- requests the demo sends
- 15
- security headers checked live
- 7
The code
Decisions
- DEC-019: A strict Content Security Policy (opens in a new tab)
- DEC-032: Visitors by /64 network and the limits from the OWASP review (opens in a new tab)
Recorded in docs/DECISIONES.md (in Spanish), with their context and the alternatives ruled out.
What if someone floods your site?
A bot floods the form
Your browser sends 15 real requests to the API, one after another, the way the bot would.
- Went through
- 0
- Blocked
- 0
A person using your site never reaches the limit. A bot does: after 10 requests in a minute, the site stops serving it until room frees up.
Meanwhile, a patient
Writes from their own connection.
I'd like an appointment next week, in the afternoon.
Their connection keeps its own count: whatever the bot does doesn't touch it.
The limit is counted per connection, with a hash of the IP and never the IP itself: stopping the bot doesn't affect anyone else.
This part is an illustration and sends nothing: from your browser, the patient would share the bot's connection and the limit would stop them too.
Live rate limit
This site's API accepts up to 10 requests per minute from the same connection. Send 15, one after another, and see when it stops you.
Why it matters
Without a limit, a program can try thousands of passwords per minute until it finds yours (brute force), or flood a form with junk messages until the service goes down. Stopping each connection after a few requests cuts off that abuse without bothering people who use the site normally.
In the OWASP Top 10:2021, this falls under A04 – Insecure Design and A07 – Identification and Authentication Failures. On this site, the contact form, the admin panel sign-in and the assistant also have their own limits.
The count lives in Postgres and is kept per connection: the API stores an irreversible hash of your IP, never the IP itself.
The protections your browser got from this siteHeaders that protect this site
With every page, the server sends security instructions that your browser follows. These came in the real response your browser just got.With every page, the server sends security instructions that your browser follows: the HTTP headers. This list comes from the real response your browser just got when it asked for the site's home page, with the values exactly as they arrived.
Checking this site's headers…
Want it for your business?
This is part of what I build in the websites service. See what's included or get a reference estimate for your case.
Curious how it is built? Look under the hood
How it works
The limit is real: AIM’s API on Cloudflare accepts 10 requests per minute per connection, keeps count in Postgres with a hash of the IP (never the IP itself) and responds with the RateLimit and Retry-After headers. It stops brute force and form abuse, which the OWASP Top 10:2021 places under A04 (Insecure Design) and A07 (Identification and Authentication Failures). The headers are read live from the home page’s response: mandatory HTTPS, frame blocking, permissions policy and the others the site sends, each with the attack it stops and its OWASP category.