Project · Intermediate · about 14 hours
Secure an API with tokens, roles and rate limits
Add login, short-lived access tokens, role-based access and per-user rate limits to a catalogue API, and test every rule.
Skills:NoSQL databases, REST APIs and HTTP, Automated testing
Part of: Software Engineer (Backend)
Data and licences
- Open Food Facts product database ↗Open Database License (ODbL); images CC BY-SA
Brief
Take the product catalogue API (from the Go project or your own) and make it safe to expose: anyone can read, editors can change products, admins can manage users, and nobody can hammer it.
What to build
Users table with Argon2 or bcrypt password hashes. Login returns a short-lived access token (for example 15 minutes) and a refresh token that is rotated on use and can be revoked.
Middleware that validates tokens (signature, expiry, audience) and a role check for each route.
Redis rate limits per user and per IP, with 429 and
Retry-After.Tests: wrong password, expired token, token signed with another key, viewer trying to edit, refresh token reuse, rate limit reached.
Write
SECURITY.md: what you protect against, what you do not, and why.
Deliverables
Repository with the service, tests and
SECURITY.md
How it is graded
Reviewers try to escalate privileges, reuse old tokens and exceed limits. Every attempt should fail with the right status code.
Stretch
Add login with an external OpenID Connect provider and keep role mapping on your side.
Deliverables
- Password login with a strong hash (Argon2 or bcrypt), short-lived access tokens and refresh tokens
- Role-based access (viewer, editor, admin) enforced on every endpoint
- Per-user and per-IP rate limits backed by Redis, returning 429 with Retry-After
- Tests for every rule, including expired and tampered tokens
How a reviewer grades it
| Criterion | Weight | What good looks like |
|---|---|---|
| Passwords and tokens are handled safely (hashing, expiry, rotation, no secrets in code) | 30% | |
| Authorisation is checked on the server for every endpoint, with tests | 30% | |
| Rate limits work and are observable | 20% | |
| Security decisions documented with their trade-offs | 20% |