What are common REST API security and design best practices?
Key REST API best practices: HTTPS, token auth, authorization, input validation, rate limiting, correct status codes, versioning, and pagination.
Expected Interview Answer
Good REST APIs use HTTPS everywhere, authenticate and authorize every request, validate all input, apply rate limiting, and follow consistent resource-oriented design with correct HTTP methods, status codes, versioning, and pagination.
On security, enforce TLS, use token-based auth (OAuth2/JWT) with least-privilege authorization, validate and sanitize input to prevent injection, never leak secrets or stack traces in errors, and add rate limiting plus CORS controls. On design, model clear resource nouns, use HTTP verbs and status codes correctly, keep responses consistent, version the API, support pagination and filtering for collections, and document with OpenAPI. These practices make the API safe, predictable, and easy for consumers to adopt and evolve.
- Protects data in transit and at rest boundaries
- Prevents common attacks like injection and abuse
- Predictable, consistent interface for consumers
- Safe evolution through versioning
- Scales via rate limiting and pagination
AI Mentor Explanation
It is like running a stadium properly: ticket gates and passes control who enters (authentication and authorization), stewards check bags for banned items (input validation), turnstiles cap the crowd to safe numbers (rate limiting), and a printed rulebook everyone shares (versioned docs) keeps the match orderly and predictable for players and fans alike.
Step-by-Step Explanation
Step 1
Enforce transport security
Serve everything over HTTPS/TLS and disable insecure ciphers so credentials and data are never sent in the clear.
Step 2
Authenticate and authorize
Use token-based auth (OAuth2/JWT) and apply least-privilege, role-based checks on every endpoint.
Step 3
Validate all input
Validate, sanitize, and constrain request bodies, params, and headers to block injection and malformed data.
Step 4
Limit and protect
Add rate limiting, throttling, and CORS controls, and never leak stack traces or secrets in error responses.
Step 5
Design consistently
Use resource nouns, correct HTTP verbs and status codes, versioning, pagination, filtering, and OpenAPI docs.
What Interviewer Expects
- HTTPS/TLS as a non-negotiable baseline
- Token-based auth with least-privilege authorization
- Input validation to prevent injection and abuse
- Rate limiting, CORS, and safe error handling
- Consistent resource design, status codes, and versioning
Common Mistakes
- Serving APIs over plain HTTP or trusting the client
- Confusing authentication with authorization
- Returning stack traces or secrets in error bodies
- Using 200 for everything instead of correct status codes
- No versioning, so changes break existing consumers
Best Answer (HR Friendly)
“A well-built API always uses encrypted connections, checks who is calling and what they are allowed to do, cleans the data it receives, and limits how often it can be called. It is also organized consistently and versioned so other teams can rely on it without surprises.”
Code Example
const helmet = require('helmet')
const rateLimit = require('express-rate-limit')
app.use(helmet())
app.use(rateLimit({ windowMs: 60_000, max: 100 }))
function authorize(role) {
return (req, res, next) => {
if (!req.user) return res.sendStatus(401)
if (!req.user.roles.includes(role)) return res.sendStatus(403)
next()
}
}
app.get('/admin/reports', authorize('admin'), (req, res) => {
res.json({ ok: true })
})Follow-up Questions
- What is the difference between authentication and authorization?
- How do you prevent injection attacks in a REST API?
- Which API versioning strategy do you prefer and why?
- How does rate limiting protect an API and how do you implement it?
- What status code should a request without valid credentials receive?
MCQ Practice
1. Which status code indicates the client is authenticated but not permitted to access a resource?
403 Forbidden means the user is known but lacks permission; 401 means authentication is missing or invalid.
2. What is the primary purpose of rate limiting?
Rate limiting caps how often a client can call the API, protecting it from abuse and denial-of-service.
3. Why version a REST API?
Versioning lets you introduce breaking changes in a new version while existing consumers keep using the old one.
Flash Cards
Authentication vs authorization? — Authentication verifies who you are; authorization decides what you are allowed to do.
Why validate input? — To block injection, malformed data, and abuse before it reaches business logic or the database.
What does rate limiting do? — Caps request frequency per client to prevent abuse, overload, and denial-of-service.
Why version an API? — So breaking changes ship in a new version while existing consumers keep working on the old one.
Continue Learning
Related Interview Questions
How do you handle versioning in a REST API?
medium
What is rate limiting and throttling in a REST API and why are they important?
medium
How do you prevent mass assignment and other input-trust failures in a REST API?
hard
How would you authenticate service-to-service REST calls, and when is mutual TLS worth it?
hard