Advanced TypeScript Patterns for Large-Scale Applications

Here's a hard truth that many TypeScript developers don't realize: type safety doesn't protect you from security vulnerabilities. I've audited codebases where teams felt secure because they used TypeScript, but they had critical XSS vulnerabilities, SQL injection risks, and authentication bypasses. TypeScript is a powerful tool, but it's not a security silver bullet.

The problem is that types are erased at runtime. All your beautiful type definitions vanish when the code compiles to JavaScript. This means malicious input, API responses with unexpected shapes, or compromised dependencies can bypass your type system entirely. You need runtime validation, not just compile-time checking.

Let me show you exactly where developers get this wrong and how to fix it. These patterns have stopped real security breaches in production systems I've worked on.

The False Sense of Security

Consider this common pattern. It looks type-safe, but it's dangerously vulnerable:

// Looks safe, but it's NOT
interface User {
  id: number;
  email: string;
  isAdmin: boolean;
}

app.post('/api/update-profile', async (req, res) => {
  // TypeScript says this is safe
  const userData: User = req.body;

  // But attacker can send:
  // { id: 123, email: "fake@evil.com", isAdmin: true }
  // TypeScript won't catch this at runtime!

  await db.users.update(userData.id, userData);
  // Boom - attacker just made themselves admin
});

The type annotation User is just a hint to the compiler. At runtime, TypeScript has no way to verify that req.body actually matches the User interface. An attacker can send any JSON they want, and TypeScript will happily compile your code without complaint.

Runtime Validation: The Real Solution

You need libraries that validate data at runtime. My go-to choices are Zod, Yup, or io-ts. They bridge the gap between compile-time types and runtime safety:

import { z } from 'zod';

// Define schema with runtime validation
const UserUpdateSchema = z.object({
  email: z.string().email(),
  name: z.string().min(2).max(100),
  // isAdmin is NOT allowed in updates!
}).strict();

app.post('/api/update-profile', async (req, res) => {
  try {
    // Validate at runtime
    const userData = UserUpdateSchema.parse(req.body);

    // If we get here, data is ACTUALLY safe
    await db.users.update(req.user.id, userData);

    res.json({ success: true });
  } catch (error) {
    if (error instanceof z.ZodError) {
      // Detailed validation errors
      res.status(400).json({
        error: 'Invalid input',
        details: error.errors
      });
    }
  }
});

// Bonus: Extract TypeScript type from schema
type UserUpdate = z.infer<typeof UserUpdateSchema>;

This approach gives you both compile-time types AND runtime validation. The .strict()call is crucial - it rejects any properties not explicitly defined in the schema. Without it, attackers could still sneak in extra fields like isAdmin.

Never Trust External Data

API responses, environment variables, local storage, cookies - all of these come from outside your type system. Always validate them:

// API Response Schema
const ApiResponseSchema = z.object({
  data: z.object({
    id: z.number(),
    email: z.string().email(),
    name: z.string()
  }),
  status: z.number()
});

async function fetchUser(id: number) {
  const response = await fetch(`/api/users/${id}`);
  const json = await response.json();

  // Validate before using
  const validated = ApiResponseSchema.parse(json);

  return validated.data;
  // If API returns unexpected data, parse() throws
  // Better to fail fast than use corrupted data
}

// Environment variables
const EnvSchema = z.object({
  DATABASE_URL: z.string().url(),
  JWT_SECRET: z.string().min(32),
  NODE_ENV: z.enum(['development', 'production', 'test'])
});

// Validate on startup
const env = EnvSchema.parse(process.env);

Branded Types for Critical Data

Some values need extra protection. User IDs, passwords, tokens - you don't want these confused with regular strings. Branded types help:

// Create branded types
type UserId = string & { readonly __brand: 'UserId' };
type SessionToken = string & { readonly __brand: 'SessionToken' };

// Factory functions with validation
function createUserId(id: string): UserId {
  if (!/^[0-9a-f]{24}$/.test(id)) {
    throw new Error('Invalid user ID format');
  }
  return id as UserId;
}

function createSessionToken(token: string): SessionToken {
  if (token.length < 32) {
    throw new Error('Invalid session token');
  }
  return token as SessionToken;
}

// Now you can't mix them up
function getUser(id: UserId) { /* ... */ }
function validateSession(token: SessionToken) { /* ... */ }

const userId = createUserId('507f1f77bcf86cd799439011');
const token = createSessionToken('secure-token-here...');

getUser(userId); // ✓ Works
// getUser(token); // ✗ Type error - can't pass SessionToken as UserId
// getUser('random-string'); // ✗ Type error - must use createUserId()