Backend Security & Threat Mitigation

The OWASP Top 10 Taxonomy & Zero-Trust Threat Modeling

In modern cloud engineering, security cannot be an afterthought added at deployment. It must be woven into system architecture through Zero-Trust Design: assuming that network boundaries are already breached, internal service communication is untrusted, and all incoming inputs are intentionally adversarial.

Deconstructing the OWASP Top 10 Enterprise Vulnerabilities

SQL & NoSQL Injection: Parser Mechanics & Defense

Injection occurs when untrusted user input alters the Abstract Syntax Tree (AST) of an interpreter parser.

How SQL String Concatenation Corrupts the AST

Consider this vulnerable authentication check:
const query = "SELECT * FROM users WHERE email = '" + req.body.email + "' AND password = '" + req.body.password + "'";
If an attacker inputs: admin@company.com' --, the generated SQL becomes:
SELECT * FROM users WHERE email = 'admin@company.com' --' AND password = '...';
The double-dash (--) comments out the entire password verification clause! The database executes the query solely on the email, granting full administrative access with zero credentials.

The Solution: Parameterized Queries (Prepared Statements)

In a Parameterized Query, the database engine compiles the SQL command structure first into an immutable execution plan using positional placeholders ($1, $2). User inputs are sent over the wire separately. Even if an input contains quotes or SQL statements, the database treats it strictly as literal string data, making SQL injection mathematically impossible.

import { Pool } from 'pg';

const pool = new Pool();

// ❌ FATAL VULNERABILITY: Raw String Concatenation
export async function insecureGetUser(email: string) {
  const sql = `SELECT * FROM users WHERE email = '${email}'`;
  return await pool.query(sql); // Injection susceptible!
}

// ✅ SECURE DEFENSE: Parameterized Query (Prepared Statement)
export async function secureGetUser(email: string) {
  const sql = 'SELECT user_id, email, password_hash FROM users WHERE email = $1';
  return await pool.query(sql, [email]); // Handled as pure scalar value
}

Cross-Site Scripting (XSS) & Cross-Site Request Forgery (CSRF)

Client-server communication requires defense against unauthorized script execution and forged cross-origin actions.

Cross-Site Scripting (XSS)

XSS occurs when an attacker tricks a web application into executing arbitrary JavaScript in a victim's browser:

• Stored XSS: Malicious script payload is persisted permanently in the backend database (e.g., in a comment field). Whenever other users load the page, the script executes in their browser context.
• Reflected XSS: Malicious script is reflected off the web server via URL query parameters (e.g., ?search=<script>...</script>).

Defenses:
• Context-aware output encoding (converting < to &lt; and > to &gt;).
• Content-Security-Policy (CSP) headers disallowing inline script execution.
• HttpOnly cookies to prevent script-based token exfiltration.

Cross-Site Request Forgery (CSRF)

CSRF exploits ambient authority: browsers automatically attach session cookies to outgoing requests regardless of which website originated the request. If an authenticated user visits an attacker's site, the malicious page can execute a hidden form submit to https://bank.com/transfer. The browser attaches the user's valid session cookie!

CORS Preflight Mechanics & HTTP Security Headers

The Same-Origin Policy (SOP) is a browser security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin (Origin = Protocol + Domain + Port).

Cross-Origin Resource Sharing (CORS) & Preflight Requests

When a frontend app at https://app.devascent.me makes an API request with custom headers or mutations (PUT, DELETE, application/json) to https://api.devascent.me, the browser sends an automatic Preflight Request using the OPTIONS method before executing the actual request.

The server evaluates the preflight headers (Origin, Access-Control-Request-Method) against an explicit whitelist and responds with permitted origins and methods.

import helmet from 'helmet';
import cors from 'cors';
import { Express } from 'express';

export function applySecurityHardening(app: Express) {
  // 1. Enterprise Helmet Suite: Injects 15+ defensive HTTP headers
  app.use(helmet({
    contentSecurityPolicy: {
      directives: {
        defaultSrc: ["'self'"],
        scriptSrc: ["'self'"],
        styleSrc: ["'self'", "https://fonts.googleapis.com"],
        imgSrc: ["'self'", "data:", "https://*.amazonaws.com"],
        connectSrc: ["'self'", "https://api.devascentacademy.me"],
        upgradeInsecureRequests: []
      }
    },
    hsts: {
      maxAge: 31536000, // 1 Year Strict Transport Security
      includeSubDomains: true,
      preload: true
    },
    frameguard: { action: 'deny' } // Anti-Clickjacking
  }));

  // 2. Whitelist-Bound CORS Policy
  const allowedOrigins = ['https://devascentacademy.me', 'https://app.devascentacademy.me'];
  app.use(cors({
    origin: (origin, callback) => {
      if (!origin || allowedOrigins.includes(origin)) {
        callback(null, true);
      } else {
        callback(new Error('Cross-Origin Request Blocked by CORS Whitelist Policy'));
      }
    },
    methods: ['GET', 'POST', 'PUT', 'PATCH', 'DELETE'],
    credentials: true,
    maxAge: 86400 // Cache Preflight response for 24 hours
  }));
}

Encryption at Rest: AES-256-GCM Authenticated Encryption

Sensitive database columns (social security numbers, payment card tokens, medical records) must be encrypted at rest. Standard encryption modes like AES-CBC are vulnerable to padding oracle attacks. Modern standards mandate Authenticated Encryption with Associated Data (AEAD) using AES-256-GCM.

import { createCipheriv, createDecipheriv, randomBytes } from 'node:crypto';

export class EncryptionService {
  private static readonly ALGORITHM = 'aes-256-gcm';
  private static readonly IV_LENGTH = 12;  // 96-bit recommended IV for GCM
  private static readonly TAG_LENGTH = 16; // 128-bit Authentication Tag

  // Encrypts plain string into IV:AuthTag:Ciphertext
  public static encrypt(plaintext: string, key: Buffer): string {
    const iv = randomBytes(this.IV_LENGTH);
    const cipher = createCipheriv(this.ALGORITHM, key, iv);

    const encrypted = Buffer.concat([
      cipher.update(plaintext, 'utf8'),
      cipher.final()
    ]);

    const authTag = cipher.getAuthTag(); // Guarantees data has not been tampered with

    return `${iv.toString('hex')}:${authTag.toString('hex')}:${encrypted.toString('hex')}`;
  }

  // Decrypts and mathematically validates authentication tag
  public static decrypt(payload: string, key: Buffer): string {
    const [ivHex, tagHex, dataHex] = payload.split(':');
    const iv = Buffer.from(ivHex, 'hex');
    const authTag = Buffer.from(tagHex, 'hex');
    const encrypted = Buffer.from(dataHex, 'hex');

    const decipher = createDecipheriv(this.ALGORITHM, key, iv);
    decipher.setAuthTag(authTag);

    return decipher.update(encrypted) + decipher.final('utf8');
  }
}

Secure File Uploads: Magic Bytes & Presigned S3 Architecture

File uploads represent an acute risk: an attacker uploading an executable script (shell.php) disguised as an image can achieve Remote Code Execution (RCE).

MIME Spoofing & Binary Magic Number Validation

Never trust file extensions (.jpg) or the client's Content-Type header. The server must validate the file's Magic Bytes: the hardcoded binary signature in the file's first few bytes (e.g., PNG files always begin with hex 89 50 4E 47 0D 0A 1A 0A; JPEG files begin with FF D8 FF).

The Production Gold Standard: S3 Presigned URLs

Directing multi-megabyte file uploads through application servers consumes CPU cycles and risks path traversal attacks (../../etc/cron.d). Production backends use Presigned URLs:

University & Industrial Examination Review