Chapter 22 — Backend Hardening & DB Compromise Prevention

Threat model — what you are actually defending against

Most "we got hacked" stories are NOT about a state actor breaking AES. They are about:

1. An exposed dev endpoint that did not require auth.
2. A SQL injection in a single query that used string concatenation.
3. An IDOR — GET /invoices/:id that didn't check ownership.
4. A leaked AWS access key in a public GitHub repo.
5. A dependency pulled in by npm install that had a backdoor.
6. Someone's laptop with a saved .env got stolen.

Defence is layered. No single control protects you. Read this whole chapter.

SQL injection — the oldest trick that still works

// ❌ DEAD ON ARRIVAL — string concatenation
const rows = await this.sequelize.query(
  `SELECT * FROM users WHERE email = '${email}'`
);
// User sends email = "x' OR '1'='1"  → returns every user
// User sends email = "x'; DROP TABLE users; --"  → enjoy
 
// ✅ Parameterised — driver escapes for you
const rows =

Sequelize's where: { ... } is always safe. Raw SQL with ? or :name placeholders is safe. Anything with template-literal interpolation of user input into a query string is a vulnerability.

Mass assignment — when Object.assign betrays you

// ❌ Trusts the entire request body
@Patch('users/:id')
async update(@Param('id') id, @Body() body) {
  const user = await this.userModel.findByPk(id

Sequelize's .update(values, { fields: [...] }) is a second line of defence:

await user.update(body, { fields: ['name', 'phone'] });   // ignores everything else

IDOR — the most common IDOR bug in the wild

Insecure Direct Object Reference: a user can access another user's data by guessing the ID.

// ❌ JWT proves "you are logged in" — but who said this user can read order 5172?
@Get('orders/:id')
async get(@Param('id') id) {
  return this.orderModel.findByPk(id);
}
 
// ✅ Always scope by ownership in the WHERE clause

Notice we return 404 (not 403) when the order is not theirs — otherwise an attacker can enumerate which order IDs exist.

This is rule 11 in Chapter 17. Apply it to every endpoint that takes an ID.

SSRF — when your server fetches a URL the user controls

// ❌ User gives a URL, your backend fetches it
@Post('webhook/test')
async test(@Body('url') url) {
  await axios.get(url);    // attacker sends url = http://169.254.169.254/...
}

169.254.169.254 is the AWS metadata endpoint. From inside an EC2/ECS task it returns IAM credentials. Your "test webhook" endpoint just leaked your AWS keys.

Mitigations:

• Block private IP ranges before fetching (10.x, 192.168.x, 169.254.x, 127.x, ::1).
• Use AWS IMDSv2 (requires a token header) so a naïve GET is useless.
• Outbound network ACL that allows only public IPs from the API tier.
• Resolve the hostname yourself, then fetch by IP, to prevent DNS rebinding.

Library ssrf-req-filter or request-filtering-agent does this for you.

XXE — XML external entities

If your service parses XML (older webhook integrations, SOAP, SAML), make sure external entities are disabled:

import { XMLParser } from 'fast-xml-parser';
const parser = new XMLParser({ allowBooleanAttributes: false });
// fast-xml-parser does NOT support external entities by design — good

Default Node parsers like libxmljs have XXE off by default since v0.19. Don't downgrade.

Prototype pollution

A nasty quirk of JavaScript: if you merge user input into an object recursively, you can write to __proto__ and pollute every object in the runtime.

// ❌ Naïve deep merge
function merge(target, src) {
  for (const k of Object.keys(src)) {
    if (typeof src[k] === 'object') merge(target

Defences:

• Use lodash.merge v4.17.21+ (older versions had this bug).
• Validate input shape with class-validator — unknown fields are stripped.
• Run with Object.freeze(Object.prototype) if you don't need to extend it.
• JSON.parse with a reviver that drops __proto__ and constructor keys.

Path traversal — ../ smuggled into a filename

// ❌ User-controlled path joins
const file = path.join('/uploads', req.params.name);  // name = "../etc/passwd"
fs.readFileSync(file);
 
// ✅ Resolve and verify containment

Better: don't accept paths from users at all. Use opaque IDs and look up the path in the DB (Chapter 19).

Command injection — never shell out with user input

// ❌ exec with template literals
import { exec } from 'child_process';
exec(`convert ${filename} out.png`);   // filename = "a.jpg; rm -rf /"
 
// ✅ Use execFile (no shell), pass args as an array
import { execFile } from 'child_process';
execFile

The exec* functions that accept argument arrays do not invoke /bin/sh, so shell metacharacters in filename are inert.

💡 Even better: avoid shelling out entirely. Use a library (sharp instead of ImageMagick CLI, pdf-lib instead of pdftk).

Authorisation bugs — beyond IDOR

Authentication answers "who are you". Authorisation answers "are you allowed to do this". Most apps get auth right and authorisation half-right.

Patterns:

• Role checks at the route level — @Roles('admin'). Necessary but coarse.
• Resource ownership checks at the service level — every fetch scoped by the requester's ID.
• Action-level checks — "this user is the maker on this transaction; only a checker can approve it."

Write the check explicitly each time. Don't make it implicit ("the JWT is valid so it must be fine"). The cost of one extra if is far less than the cost of a privilege escalation.

Rate limiting & abuse

Without rate limits:

• A single attacker can brute-force a login endpoint at 10,000 attempts/sec.
• A bug in the frontend retry loop can DDOS your own API.
• A scraper can pull every record paginated by 1.

Use @nestjs/throttler or express-rate-limit:

@UseGuards(ThrottlerGuard)
@Throttle({ default: { limit: 5, ttl: 60_000 } })   // 5 attempts per minute
@Post('login')
login(...) { }

Tighter limits on sensitive endpoints (login, password reset, OTP, SMS sends). Looser on read endpoints.

Database compromise — what really happens

A "database compromise" usually means one of:

1. Stolen credentials — .env file leaked, IAM key in a public repo.
2. SQL injection that escalated to data exfil.
3. Open port — RDS publicly accessible, no IP allowlist.
4. Admin panel without auth — pgAdmin / phpMyAdmin exposed on the internet.
5. Insider — an engineer with prod access went rogue.

The defences are concentric circles. You want all of them.

Network isolation

The DB should sit in a private subnet with no route to the internet. The app servers connect to it. The internet does not.

Internet → ALB (public subnet)
            → API instances (private subnet)
              → RDS PostgreSQL (isolated subnet, only the API SG allowed)

If the only way to talk to the DB is through your API, an attacker who steals the DB credentials still cannot use them from their laptop.

Least-privilege DB users

Don't run the application as the database superuser. Create three users:

CREATE ROLE app_writer LOGIN PASSWORD '...';   -- INSERT/UPDATE/DELETE/SELECT, no DDL
CREATE ROLE app_reader LOGIN PASSWORD '...';   -- SELECT only — for read replicas
CREATE ROLE migrations LOGIN PASSWORD '...';   -- DDL — used only by CI to run migrations
 
GRANT SELECT ON ALL TABLES 

The app's main connection uses app_writer. A SQL injection bug becomes "attacker can read/write data" but not "attacker can DROP TABLE users" or "attacker can read pg_shadow to dump password hashes."

Encryption everywhere

• At rest: enable disk encryption on the RDS instance (free; one toggle).
• In transit: require sslmode=require from the client. Reject non-TLS connections at the DB.
• Field-level encryption for the most sensitive columns (Aadhaar, PAN, card numbers) using a KMS key. Even an SQL injection that dumps the table gets ciphertext.

Backups + Point-in-Time Recovery

RDS gives you PITR for free. Turn it on with a 35-day window. Test the restore — a backup you've never restored is not a backup, it's a hope.

1. Create a new RDS instance from a snapshot 24 hours old
2. Confirm rows are correct
3. Tear it down

Do this drill once a quarter.

Audit logs

pgAudit extension logs every DDL and DML event. Pipe these to CloudWatch / S3 with a retention policy. After an incident, you want to be able to answer "which rows did the attacker read".

Secrets management

.env files are fine for local dev. They are not fine for production.

In production:

• AWS Secrets Manager / HashiCorp Vault / Doppler holds the secret.
• The app loads it at boot via IAM role, not a long-lived API key.
• Rotation is automated (Secrets Manager will rotate RDS passwords for you).
• Access is logged — every secret read shows up in CloudTrail.

Other rules:

• Never commit a .env — .env belongs in .gitignore. Use git-secrets as a pre-commit hook to block accidental commits.
• No secrets in logs — pino/winston redactors that strip password, token, secret keys from any log line (Chapter 12).
• Different secrets per environment — dev secrets cannot decrypt prod data.
• Rotate after every offboarding — anyone leaves the team, every secret they could have seen rotates.

Dependency security

Your code is maybe 5% of what runs in production. The other 95% is npm packages.

• npm audit in CI — fail on --audit-level=high.
• Dependabot / Renovate — auto-PRs for vulnerable deps.
• npm ci not npm install in production builds — uses the lockfile exactly.
• Pin transitive deps with overrides in package.json when a sub-dep is known-bad.
• Watch for typosquatting — node-fetch is real, node-feth is malware.
• Audit new deps before adding — who maintains it, when was last release, how many GitHub stars, how many open security issues.

The Solar Winds, ua-parser-js, event-stream, colors.js incidents all happened because nobody read the latest commit before pulling in a transitive update.

Logging without leaking

Logs are useful and dangerous:

// ❌ Logs the entire request including the password
logger.log(`Login attempt: ${JSON.stringify(req.body)}`);
 
// ❌ Logs the JWT in the auth header
logger.log(`Headers: ${JSON.stringify(req

PII leaking into logs is a real GDPR / DPDPA violation. Set up redaction (Chapter 12) and review your log lines.

Headers and CORS — the easy wins

// main.ts
app.use(helmet());                            // sets ~10 security headers
app.enableCors({
  origin: ['https://app.example.com'],        // never '*' for authed APIs
  credentials: true,
});

helmet() sets:

• Strict-Transport-Security (HSTS)
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• Content-Security-Policy
• Referrer-Policy

Five lines, enormous return.

The OWASP top 10 checklist (memorise it)

If you can talk through every item with a real example from this codebase, you’re hireable.

A short anti-pattern roundup

❌ String-concat into SQL. ❌ Object.assign(model, req.body). ❌ findByPk(id) without ownership scope. ❌ User-controlled URL in axios.get(url). ❌ child_process.exec() with template literals. ❌ Public bucket / public RDS. ❌ Same secret across environments. ❌ Logging the request body. ❌ cors({ origin: '*' }) on an authed API. ❌ Running the app as the DB superuser. ❌ Skipping npm audit in CI.

The hardening checklist (run through this quarterly)

• All secrets in Secrets Manager / Vault, not .env
• DB in a private subnet, only the API security group allowed
• Three DB roles: writer, reader, migrations
• PITR enabled, restore drill done in last 90 days
• HTTPS everywhere; HSTS preloaded
• Helmet + correct CORS allowlist
• Rate limiting on login, OTP, password reset
• WAF in front (Cloudflare / AWS WAF)
• npm audit in CI; Dependabot enabled
• Pre-commit hook for secret scanning
• Log redactors for tokens, passwords, PII
• No public S3 buckets; all server-side encrypted
• CloudTrail / pgAudit on; logs shipped to a separate account
• All endpoints authorised (route-level role + resource ownership check)
• No SSRF reachable endpoints; outbound traffic restricted