API Security Threats 2026: Injection, Broken Auth, Rate Limiting & Protection
APIs are the arteries of modern applications—they move data between microservices, mobile clients, third-party integrations, and partner networks. But they're also attack surfaces. In 2026, API security breaches are the leading cause of data loss in SaaS platforms. This guide covers the threats that matter most and defenses that actually work.
1. Injection Attacks: The persistent nightmare
SQL injection, NoSQL injection, and command injection remain the most exploited API vulnerabilities. The pattern is always the same: untrusted user input flows into a backend query without sanitization.
SQL Injection via API
The attack: An attacker crafts a query parameter to close a SQL statement early and inject malicious SQL:
GET /api/users?id=1 OR 1=1
// Backend code (Node.js)
const query = `SELECT * FROM users WHERE id = ${req.query.id}`;
db.query(query); // Executes: SELECT * FROM users WHERE id = 1 OR 1=1
// Returns ALL users, not just id=1
The fix: Use parameterized queries (prepared statements):
const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [req.query.id]); // Driver handles escaping
// ORMs are safer
User.findById(req.query.id); // Parameterized by default
NoSQL Injection
Even NoSQL databases aren't immune. Attackers can inject query operators:
db.collection('users').findOne({ email: req.body.email });
// If attacker sends: { "email": { "$ne": null } }
// Query becomes: findOne({ email: { $ne: null } })
// Returns first user regardless of email
// Secure: validate input schema first
const schema = z.object({ email: z.string().email() });
const validated = schema.parse(req.body);
db.collection('users').findOne({ email: validated.email });
2. Broken Authentication & Authorization
APIs often implement weak authentication—hardcoded API keys, expired tokens accepted, or missing role checks.
Common vulnerabilities:
- Hardcoded API keys: Secrets embedded in code or published in public GitHub repositories.
- Expired tokens accepted: API continues to honor JWT tokens after expiration.
- Missing role checks: Admin-only endpoints don't verify user role before execution.
- Credential stuffing: Attackers use leaked username/password pairs to brute-force login endpoints.
- CORS misconfiguration: API allows requests from untrusted origins, enabling cross-origin token theft.
Hardened authentication pattern:
const keyHash = bcrypt.hashSync(apiKey, 10);
db.apiKeys.insert({ userId, hash: keyHash, createdAt: now });
// 2. Verify token and check expiration
router.use((req, res, next) => {
const token = req.headers.authorization?.split(' ')[1];
try {
const decoded = jwt.verify(token, SECRET, { algorithms: ['HS256'] });
if (decoded.exp < Date.now() / 1000) throw new Error('Token expired');
req.user = decoded;
next();
} catch (err) { res.status(401).json({ error: 'Unauthorized' }); }
});
// 3. Enforce roles on protected endpoints
router.delete('/users/:id', requireRole('admin'), (req, res) => {
// Only admins can reach this
});
3. Insufficient Rate Limiting & API Abuse
Without rate limits, attackers can scrape your entire database, enumerate users, or launch credential stuffing attacks at scale.
Attack scenarios:
Attacker iterates through sequential IDs: GET /api/users/1, /api/users/2, /api/users/3... without rate limits, they download all user records in minutes.
Attacker sends login requests with leaked passwords: POST /api/login with 1M attempts/day. Even a 1% success rate compromises 10,000 accounts.
Effective rate limiting strategy:
const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
store: new RedisStore({
client: redisClient,
prefix: 'rl:' // rate limit prefix
}),
windowMs: 60 * 1000, // 1 minute
max: 100, // 100 requests per minute
keyGenerator: (req) => req.user.id || req.ip, // Per-user or per-IP
handler: (req, res) => {
res.status(429).json({ error: 'Too many requests' });
logSuspiciousActivity(req); // Alert on abuse pattern
}
});
// Apply to sensitive endpoints
router.post('/login', limiter, loginHandler);
router.get('/api/users', limiter, getUsers);
4. Mass Data Exposure (Information Disclosure)
APIs often leak sensitive data through verbose error messages, over-permissive responses, or missing pagination.
Vulnerability: Unbounded queries
GET /api/transactions
// Returns ALL transactions (millions of records)
// Secure: Enforce pagination
GET /api/transactions?page=1&limit=50
router.get('/transactions', (req, res) => {
const limit = Math.min(parseInt(req.query.limit) || 50, 100); // Max 100
const page = Math.max(parseInt(req.query.page) || 1, 1);
const offset = (page - 1) * limit;
const transactions = Transaction.find()
.skip(offset)
.limit(limit);
res.json({ data: transactions, page, limit, total: await Transaction.count() });
});
Vulnerability: Over-permissive responses
API returns user objects with sensitive fields (password hash, internal IDs, payment info):
{ "id": 123, "name": "John", "email": "...", "passwordHash": "bcrypt...", "internalId": "..." }
// Secure: Use serialization layer
class UserSerializer {
toJSON(user) {
return {
id: user.id,
name: user.name,
email: user.email
// passwordHash, internalId excluded
};
}
}
res.json(new UserSerializer().toJSON(user));
5. Broken Object Level Authorization (BOLA)
A user accesses another user's data by changing an ID in the URL: GET /api/users/999 (where they own /api/users/123). If the API doesn't verify ownership, they see another user's private data.
router.get('/users/:id', (req, res) => {
const user = User.findById(req.params.id);
res.json(user); // No ownership check
});
// Secure: Verify ownership
router.get('/users/:id', authenticate, (req, res) => {
const user = User.findById(req.params.id);
if (user.id !== req.user.id && !req.user.isAdmin) {
return res.status(403).json({ error: 'Forbidden' });
}
res.json(user);
});
API Security Checklist
- ✓ All inputs validated against schema (zod, joi, yup)
- ✓ All database queries use parameterized statements
- ✓ Authentication enforced on all protected endpoints
- ✓ Tokens have short expiration times (15min access, 7day refresh)
- ✓ Rate limiting active per-user and per-IP
- ✓ Pagination enforced (max 100 records per request)
- ✓ Authorization checks on resource access (BOLA protection)
- ✓ Sensitive fields excluded from response serialization
- ✓ Error messages don't leak internal system details
- ✓ All API access logged with timestamps and user IDs
- ✓ CORS headers restricted to trusted origins
- ✓ HTTPS enforced; HTTP redirects to HTTPS
Securing APIs is a continuous process. The threats evolve as attackers discover new patterns. This is the foundation I build for teams developing SaaS platforms and microservices architectures.