← Back to articles

Backend Security

· 3 min read · backend · ... views
Share: Y
On this page

Every backend connected to the internet is under attack. Bots scan for vulnerabilities 24/7. If you leave a door open, someone will walk through it. Let’s cover the attacks you’ll face and how to defend against them.

The OWASP Top Threats

Attack Types

SQL Injection, attacker manipulates your database queries

// Vulnerable
query("SELECT * FROM users WHERE name = '" + userInput + "'")
// Input: "'; DROP TABLE users; --"

Fix: always use parameterized queries / prepared statements.

Cross-Site Scripting (XSS), attacker injects JavaScript into your pages Fix: sanitize all user-generated content before rendering. Escape HTML.

Broken Authentication, weak passwords, exposed tokens, no rate limiting on login Fix: bcrypt/argon2 for passwords, short-lived JWTs, rate limiting, MFA.

Insecure Direct Object References, user changes /orders/42 to /orders/43 and sees someone else’s order Fix: always check ownership. “Does THIS user own THIS resource?”

Defense in Depth

Defense Layers

Security isn’t one thing. It’s layers:

  1. Network layer, firewalls, VPNs, private subnets
  2. Transport layer, HTTPS everywhere (TLS certificates)
  3. Application layer, input validation, auth, rate limiting
  4. Data layer, encryption at rest, minimal permissions, no sensitive data in logs

If one layer fails, the next one catches it.

Practical Security Checklist

  • Use HTTPS everywhere (no exceptions)
  • Hash passwords with bcrypt (cost factor 12+)
  • Validate and sanitize ALL input
  • Use parameterized queries (never concatenate SQL)
  • Set security headers (HSTS, X-Frame-Options, CSP)
  • Rate limit authentication endpoints
  • Use short-lived tokens (15 min JWT + refresh token)
  • Don’t expose stack traces or internal errors to users
  • Keep dependencies updated (Dependabot, Snyk)
  • Principle of least privilege (each service gets minimum permissions)
  • Encrypt sensitive data at rest
  • Log security events (failed logins, permission denied, unusual patterns)

CORS, The Misunderstood Security Feature

CORS isn’t really about protecting your server. It protects your users’ browsers from being tricked into making requests they didn’t intend.

Your server should explicitly declare which origins (domains) are allowed to call it:

Access-Control-Allow-Origin: https://myapp.com

Never use * in production unless it’s truly a public API.

Wrapping Up

  • Security is layers, not a single solution
  • SQL injection and XSS are still the top threats, prevent them
  • Always validate input, hash passwords, use HTTPS
  • Check authorization (ownership) on every request
  • Keep dependencies updated
  • Log everything security-related

Day 18 of 95 | Backend Engineering Series

Enjoyed this article?
Share: Y

Get new articles in your inbox

No spam. Unsubscribe anytime.

Get in touch

Have a question, feedback, or just want to say hi? Reach out.