DEV Community: Rasim Çarkçı

HMAC Authentication: What It Is and How It Works

Rasim Çarkçı — Sat, 31 Oct 2026 16:09:12 +0000

Passwords and API keys get stolen. HMAC proves a message was sent by someone who holds a shared secret — without ever sending the secret itself. Here is how it works and how to implement it.

Originally published on MoreOnlineTools Blog.

What Is HMAC?

HMAC stands for Hash-based Message Authentication Code. It is a mechanism that uses a cryptographic hash function combined with a shared secret key to verify two things simultaneously: that a message has not been tampered with (integrity), and that it was sent by someone who possesses the shared secret (authenticity).

In the simplest terms, HMAC produces a fixed-length "signature" of a message. The sender computes this signature using their secret key and attaches it to the message. The receiver independently computes the same signature using their copy of the same secret key. If the two signatures match, the message is authentic and intact. If they do not match, either the message was tampered with or the sender does not hold the correct key.

HMAC is not encryption. It does not hide the content of a message — a third party can read the payload. What HMAC proves is who sent it and that it was not changed in transit. If you need confidentiality, combine HMAC with encryption (HTTPS already does this for you in transit).

The Two Problems HMAC Solves

Integrity: Any change to the message — even a single bit flip — produces a completely different HMAC signature. An attacker cannot modify the payload without invalidating the signature (assuming they do not have the secret key).
Authenticity: Only someone who holds the shared secret can produce a valid HMAC. An attacker who intercepts the message cannot forge a valid signature for a new payload.

The HMAC Algorithm Step by Step

HMAC is defined in RFC 2104. The formal definition looks intimidating, but the logic is straightforward once you break it down.

The formula for HMAC-SHA256 (using SHA-256 as the hash function) is:

HMAC(K, m) = H( (K' ⊕ opad) || H( (K' ⊕ ipad) || m ) )

Where:

H — the hash function (SHA-256 in our case)
K — the secret key
K' — the key padded or hashed to the block size of the hash function (64 bytes for SHA-256)
m — the message
ipad — inner padding: the byte 0x36 repeated 64 times
opad — outer padding: the byte 0x5C repeated 64 times
⊕ — XOR operation
|| — concatenation

Step-by-Step Walkthrough

Prepare the key: If the key is shorter than the block size (64 bytes for SHA-256), pad it with zeros. If it is longer, hash it first to reduce it to the block size.
Inner hash: XOR the padded key with ipad, concatenate the message, and hash the result: H((K' ⊕ ipad) || m).
Outer hash: XOR the padded key with opad, concatenate the inner hash result, and hash again: H((K' ⊕ opad) || inner_hash).
Result: The output of the outer hash is the HMAC signature — 32 bytes (256 bits) for HMAC-SHA256.

Why Two Rounds of Hashing?

A naive approach might be to simply hash the key and message together: H(K || m). This is vulnerable to a length extension attack: an attacker who knows H(K || m) can compute H(K || m || extra_data) without knowing K, simply by appending data and continuing the hash computation.

The two-round construction (inner hash + outer hash with different XOR pads) prevents this entirely. The outer hash wraps the inner hash result, making length extension impossible. This is what makes HMAC secure where simple keyed hashes are not.

Do not invent your own MAC scheme. HMAC has been formally analyzed and proven secure. Custom constructions like H(key + message) or H(message + key) have well-documented attacks. Use HMAC as specified.

HMAC vs Other Authentication Methods

Understanding where HMAC fits compared to other authentication mechanisms helps you choose the right tool for the right job.

Method	How It Works	Replay Protection	Stateless	Best For
API Key	Static token sent with every request	None	Yes	Simple server-to-server, low-risk APIs
Basic Auth	Username:password Base64-encoded in header	None	Yes	Internal tools, legacy systems
JWT	Self-contained token signed with secret or private key	Optional	Yes	User authentication, session management
HMAC Signature	Request payload signed with shared secret + timestamp	Built-in	Yes	Webhooks, payment callbacks, inter-service APIs
OAuth 2.0	Delegated access with short-lived tokens	Yes	Partial	Third-party access, user-facing APIs

When to Use HMAC Over JWT

JWT and HMAC are sometimes confused because both involve signing with a secret key. The key difference is what they sign:

JWT signs a structured payload (claims about a user or session) and is typically used for identity — proving who the caller is.
HMAC webhook signatures sign the raw request body and timestamp, and are used for message integrity — proving that a specific payload came from a specific sender and has not been modified.

Use HMAC when a server needs to verify that incoming HTTP requests (especially webhooks) genuinely came from a trusted party and were not replayed or tampered with. Use JWT when you need to pass user identity claims between services.

Webhook Signature Verification

The most common real-world use of HMAC is webhook signature verification. When GitHub, Stripe, Shopify, or any payment processor sends a webhook to your server, they include an HMAC signature so you can verify the request is legitimate before acting on it.

The pattern works like this:

When you register a webhook endpoint, you provide (or receive) a shared secret.
When the sender fires a webhook, it computes HMAC-SHA256(secret, payload) — often including a timestamp in the signed data.
The sender includes the signature in a request header (e.g. X-Hub-Signature-256, Stripe-Signature).
Your server receives the request, independently computes the same HMAC, and compares signatures using constant-time comparison.
If signatures match: process the webhook. If not: reject it with a 401.

Why include a timestamp?

Without a timestamp in the signed data, an attacker who captures a valid request can replay it indefinitely — the signature will always be valid. Including the current timestamp (and rejecting requests older than 5 minutes) prevents replay attacks.

Timing Attacks — The Hidden Danger

This is the most important security detail that most HMAC tutorials skip. Even if your HMAC implementation is mathematically correct, a naive string comparison can leak the secret key through timing attacks.

How Timing Attacks Work

Standard string comparison (===, ==, strcmp) returns false as soon as it finds the first differing character. This means the comparison takes longer for strings that share a longer common prefix. An attacker can measure the response time of thousands of requests to statistically determine — byte by byte — what the correct HMAC signature is, without ever knowing the secret key.

This is not theoretical. Timing attacks on HMAC comparisons have been demonstrated in practice against production systems.

Never use regular string comparison for HMAC verification. Always use a constant-time comparison function that takes the same amount of time regardless of how many characters match.

Constant-Time Comparison by Language

Language	Safe Function	Unsafe
PHP	`hash_equals($known, $user)`	`$a === $b`
Python	`hmac.compare_digest(a, b)`	`a == b`
Node.js	`crypto.timingSafeEqual(a, b)`	`a === b`
Go	`hmac.Equal(a, b)`	`a == b`
Ruby	`Rack::Utils.secure_compare(a, b)`	`a == b`

Implementation Examples

The following are complete, production-ready webhook verification functions for the three most common server-side languages. Each includes HMAC computation, timestamp validation, and constant-time comparison.

PHP Implementation

<?php

/**
 * Verify an incoming webhook signature.
 *
 * @param string $payload     Raw request body (do NOT parse first)
 * @param string $signature   Signature from request header (e.g. sha256=abc123...)
 * @param string $secret      Your shared webhook secret
 * @param int    $timestamp   Unix timestamp from header (0 to skip check)
 * @param int    $tolerance   Max age in seconds (default: 300 = 5 minutes)
 * @return bool
 */
function verifyWebhookSignature(
    string $payload,
    string $signature,
    string $secret,
    int $timestamp = 0,
    int $tolerance = 300
): bool {
    // Replay attack protection
    if ($timestamp > 0) {
        $age = abs(time() - $timestamp);
        if ($age > $tolerance) {
            return false; // Request too old (or from the future)
        }
    }

    // Compute the expected HMAC
    // Include timestamp in signed data if provided
    $signed_payload = $timestamp > 0
        ? "{$timestamp}.{$payload}"
        : $payload;

    $expected = 'sha256=' . hash_hmac('sha256', $signed_payload, $secret);

    // CRITICAL: constant-time comparison to prevent timing attacks
    return hash_equals($expected, $signature);
}

// Example usage — GitHub webhook
$payload   = file_get_contents('php://input');
$signature = $_SERVER['HTTP_X_HUB_SIGNATURE_256'] ?? '';
$secret    = 'your_webhook_secret_here';

if (!verifyWebhookSignature($payload, $signature, $secret)) {
    http_response_code(401);
    exit('Invalid signature');
}

// Safe to process
$data = json_decode($payload, true);

Python Implementation

import hmac
import hashlib
import time
from typing import Optional


def verify_webhook_signature(
    payload: bytes,
    signature: str,
    secret: str,
    timestamp: Optional[int] = None,
    tolerance: int = 300
) -> bool:
    """
    Verify an incoming webhook signature using HMAC-SHA256.

    Args:
        payload:   Raw request body bytes (do NOT decode/parse first)
        signature: Signature from request header (e.g. 'sha256=abc123...')
        secret:    Shared webhook secret
        timestamp: Unix timestamp from request header (None to skip check)
        tolerance: Max age in seconds (default: 300 = 5 minutes)

    Returns:
        True if signature is valid, False otherwise
    """
    # Replay attack protection
    if timestamp is not None:
        age = abs(int(time.time()) - timestamp)
        if age > tolerance:
            return False

    # Build the signed payload
    if timestamp is not None:
        signed_payload = f"{timestamp}.".encode() + payload
    else:
        signed_payload = payload

    # Compute expected HMAC
    expected_digest = hmac.new(
        secret.encode('utf-8'),
        signed_payload,
        hashlib.sha256
    ).hexdigest()
    expected = f"sha256={expected_digest}"

    # CRITICAL: constant-time comparison to prevent timing attacks
    return hmac.compare_digest(expected, signature)


# Example usage — Flask webhook handler
from flask import Flask, request, abort

app = Flask(__name__)
WEBHOOK_SECRET = "your_webhook_secret_here"

@app.route('/webhook', methods=['POST'])
def webhook():
    payload = request.get_data()  # Raw bytes, before parsing
    signature = request.headers.get('X-Hub-Signature-256', '')

    if not verify_webhook_signature(payload, signature, WEBHOOK_SECRET):
        abort(401, "Invalid signature")

    data = request.get_json()
    # Safe to process...
    return '', 200

JavaScript / Node.js Implementation

const crypto = require('crypto');

/**
 * Verify an incoming webhook signature using HMAC-SHA256.
 *
 * @param {string|Buffer} payload   Raw request body (string or Buffer)
 * @param {string}        signature Signature header value (e.g. 'sha256=abc123...')
 * @param {string}        secret    Shared webhook secret
 * @param {number}        [timestamp]  Unix timestamp (seconds) — pass 0 or omit to skip
 * @param {number}        [tolerance]  Max age in seconds (default: 300)
 * @returns {boolean}
 */
function verifyWebhookSignature(payload, signature, secret, timestamp = 0, tolerance = 300) {
    // Replay attack protection
    if (timestamp > 0) {
        const age = Math.abs(Math.floor(Date.now() / 1000) - timestamp);
        if (age > tolerance) {
            return false;
        }
    }

    // Build the signed payload (include timestamp if provided)
    const signedPayload = timestamp > 0
        ? `${timestamp}.${payload}`
        : payload;

    // Compute expected HMAC
    const expectedDigest = crypto
        .createHmac('sha256', secret)
        .update(signedPayload)
        .digest('hex');
    const expected = `sha256=${expectedDigest}`;

    // CRITICAL: constant-time comparison to prevent timing attacks
    // Buffers must be the same length for timingSafeEqual
    const a = Buffer.from(expected, 'utf8');
    const b = Buffer.from(signature, 'utf8');

    if (a.length !== b.length) {
        // Length difference already reveals mismatch, but we still
        // run the comparison to avoid timing leaks on length alone
        crypto.timingSafeEqual(a, Buffer.alloc(a.length));
        return false;
    }

    return crypto.timingSafeEqual(a, b);
}

// Example usage — Express.js webhook handler
const express = require('express');
const app = express();

// IMPORTANT: use raw body parser, not JSON parser
app.use('/webhook', express.raw({ type: 'application/json' }));

const WEBHOOK_SECRET = 'your_webhook_secret_here';

app.post('/webhook', (req, res) => {
    const payload = req.body;          // Buffer from raw parser
    const signature = req.headers['x-hub-signature-256'] || '';

    if (!verifyWebhookSignature(payload, signature, WEBHOOK_SECRET)) {
        return res.status(401).send('Invalid signature');
    }

    const data = JSON.parse(payload);
    // Safe to process...
    res.sendStatus(200);
});

Parse after verification, not before. Always verify the HMAC signature using the raw request body before parsing it as JSON. If you parse JSON first, the body middleware may re-serialize it slightly differently, causing the signature to fail even for valid requests.

Choosing the Right Hash Function

HMAC is not tied to a single hash function — you choose which one to use. The choice determines the output length, performance, and security level of your signatures.

Algorithm	Output Size	Security Level	Recommendation
HMAC-MD5	128 bits (16 bytes)	Broken	Legacy compatibility only. MD5 has known collision attacks. Never use for new systems.
HMAC-SHA1	160 bits (20 bytes)	Weak	SHA-1 collisions are feasible. Avoid for new projects. Some older APIs (like early GitHub webhooks) still use it.
HMAC-SHA256	256 bits (32 bytes)	Strong	Recommended. The industry standard for webhooks and APIs. Used by GitHub, Stripe, Shopify, AWS.
HMAC-SHA384	384 bits (48 bytes)	Strong	Higher security margin. Reasonable choice if your threat model demands it.
HMAC-SHA512	512 bits (64 bytes)	Maximum	Highest security margin. Slightly faster than SHA-256 on 64-bit hardware. Use for high-assurance systems.

For most web applications and webhook verification use cases, HMAC-SHA256 is the correct choice. It is well-supported across every major language and platform, has no known practical attacks, and produces a compact 64-character hex signature.

Common Mistakes

1. Sending the Secret in the Request

This defeats the entire purpose of HMAC. The secret key must never leave your server — it is used to sign requests, not to authenticate them by transmission. If you are putting your secret in an HTTP header for the receiver to compare, you are doing this wrong. Use the secret to compute an HMAC and send the HMAC instead.

2. Not Including a Timestamp

An HMAC without a timestamp is vulnerable to replay attacks. If an attacker intercepts a valid signed request, they can re-send it hours or days later — the HMAC will still be valid because the payload has not changed. Always include the current Unix timestamp in the signed data and reject requests older than a few minutes (5 minutes is the standard window used by Stripe and GitHub).

3. Using Regular String Comparison

As explained in the timing attacks section: ===, ==, and strcmp are vulnerable. Always use hash_equals() (PHP), hmac.compare_digest() (Python), or crypto.timingSafeEqual() (Node.js).

4. Reusing the Same Secret Across Multiple Services

If you use the same HMAC secret for your payment webhook and your deployment webhook, a compromise of either service exposes both. Generate a separate, unique secret for each integration. Secrets are cheap; breaches are not.

5. Using a Short or Weak Secret Key

The security of HMAC depends entirely on the entropy of the secret key. A 6-character password is not a suitable HMAC key. The recommendation from NIST is that the secret key should be at least as long as the output of the hash function — so 32 bytes (256 bits) for HMAC-SHA256. Use a cryptographically secure random generator:

# Generate a strong 32-byte secret key

# PHP
$secret = bin2hex(random_bytes(32)); // 64-character hex string

# Python
import secrets
secret = secrets.token_hex(32)       # 64-character hex string

# Node.js
const secret = require('crypto').randomBytes(32).toString('hex');

# Bash / shell
openssl rand -hex 32

6. Verifying the Signature After Processing the Request

Verify first, act second — always. Do not insert records into your database, send emails, or trigger any side effects before you have confirmed the HMAC signature. An invalid signature means the request should be rejected immediately, before any business logic runs.

Real-World Examples

Looking at how major platforms implement HMAC helps you understand both the pattern and the variations you will encounter in practice.

GitHub Webhooks

GitHub sends a X-Hub-Signature-256 header with the format sha256=<hex_digest>. The signature is computed as HMAC-SHA256(secret, raw_body) — no timestamp is included in the signed data (GitHub handles replay prevention at the delivery level).

# GitHub webhook header example
X-Hub-Signature-256: sha256=d10f4b7d5c98a31c1f3b2e4d5a67890b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f

# Verification (PHP)
$expected = 'sha256=' . hash_hmac('sha256', $raw_body, $secret);
$valid = hash_equals($expected, $_SERVER['HTTP_X_HUB_SIGNATURE_256']);

Stripe Webhooks

Stripe's approach is more comprehensive. The Stripe-Signature header contains both the timestamp and one or more v1 HMAC signatures. The signed payload is timestamp.raw_body. Multiple signatures may appear during secret rotation.

# Stripe webhook header example
Stripe-Signature: t=1706123456,v1=abc123...,v1=def456...

# Stripe-style verification (PHP)
function verifyStripeSignature(string $payload, string $sig_header, string $secret): bool {
    $parts = [];
    foreach (explode(',', $sig_header) as $part) {
        [$k, $v] = explode('=', $part, 2);
        $parts[$k][] = $v;
    }

    $timestamp = (int)($parts['t'][0] ?? 0);
    if (abs(time() - $timestamp) > 300) return false; // 5-minute tolerance

    $signed = $timestamp . '.' . $payload;
    $expected = hash_hmac('sha256', $signed, $secret);

    foreach ($parts['v1'] ?? [] as $sig) {
        if (hash_equals($expected, $sig)) return true;
    }
    return false;
}

AWS Signature Version 4

AWS takes HMAC to its most sophisticated form. AWS SigV4 derives a signing key through a chain of four nested HMACs before signing the final request. This derives a date-scoped, region-scoped, service-scoped key from the main secret:

# AWS SigV4 key derivation (simplified)
# Each step uses the previous result as the key for the next HMAC

date_key     = HMAC-SHA256("AWS4" + secret_key,   date)
region_key   = HMAC-SHA256(date_key,              region)
service_key  = HMAC-SHA256(region_key,            service)
signing_key  = HMAC-SHA256(service_key,           "aws4_request")

# The signing key is then used to sign the "string to sign"
signature    = HMAC-SHA256(signing_key,           string_to_sign)

This chained approach means that even if a day-scoped key is leaked, it cannot be used to sign requests for other services, regions, or days. It demonstrates how HMAC can be used as a key derivation function (KDF) as well as a MAC.

HMAC secures the channel between your servers. For protecting the network layer — encrypting traffic in transit and blocking threats before they reach your infrastructure — NordVPN Threat Protection adds a complementary defense layer that works independently of your application code.

SQL Injection Prevention: Developer's Security Checklist

Rasim Çarkçı — Sat, 17 Oct 2026 13:46:59 +0000

SQL injection is still the number one cause of data breaches — and it is entirely preventable. This checklist covers every layer of defense: parameterized queries, ORMs, input validation, least-privilege databases, and WAF rules.

Originally published on MoreOnlineTools Blog.

Why SQL Injection Is Still Top of the OWASP List

SQL injection (SQLi) has topped the OWASP Top 10 list of web application security risks for over a decade. Despite being a well-understood attack, it causes millions of breaches every year — from small WordPress sites to Fortune 500 databases. The reason is simple: developers under deadline skip validation, copy unsafe code snippets from tutorials, or trust that ORMs handle everything automatically (they do not, if you bypass them).

A successful SQL injection lets an attacker:

Dump your entire database (usernames, passwords, credit cards, PII)
Bypass authentication (login as any user without knowing their password)
Modify or delete data silently
Execute OS-level commands on poorly configured database servers
Use your database server as a beachhead for lateral movement

How SQL Injection Works

The root cause is always the same: user-controlled input is concatenated directly into a SQL query. When the database engine cannot distinguish between SQL code and data, an attacker can change the structure of the query itself.

Classic example — unsafe PHP login:

// UNSAFE — never do this
$query = "SELECT * FROM users WHERE username = '" . $_POST['username'] . "'
          AND password = '" . md5($_POST['password']) . "'";

An attacker enters the username: admin'--

The resulting query becomes:

SELECT * FROM users WHERE username = 'admin'--' AND password = '...'

The -- starts a SQL comment, nullifying the password check. The attacker is now logged in as admin without knowing the password. More destructive payloads can use UNION SELECT to exfiltrate data or ; DROP TABLE users; -- to destroy it.

Defense Layer 1: Parameterized Queries (Prepared Statements)

This is the single most important defense. With parameterized queries, you send the SQL structure to the database engine separately from the data. The engine compiles the query first, then binds the data — no matter what the data contains, it can never alter the query structure.

PHP (PDO)

// SAFE — parameterized query with PDO
$pdo = new PDO('mysql:host=localhost;dbname=mydb', $user, $pass, [
    PDO::ATTR_EMULATE_PREPARES => false,  // critical: use real prepared statements
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

$stmt = $pdo->prepare('SELECT * FROM users WHERE username = ? AND active = ?');
$stmt->execute([$_POST['username'], 1]);
$user = $stmt->fetch();

Important: Set PDO::ATTR_EMULATE_PREPARES => false. Without it, PDO emulates prepared statements in PHP rather than using real DB-level parameterization.

PHP (MySQLi)

$conn = new mysqli('localhost', $user, $pass, 'mydb');
$stmt = $conn->prepare('SELECT * FROM users WHERE username = ? AND active = ?');
$stmt->bind_param('si', $_POST['username'], 1);
$stmt->execute();
$result = $stmt->get_result();

Python (psycopg2 / PostgreSQL)

cursor.execute(
    "SELECT * FROM users WHERE username = %s AND active = %s",
    (request.form['username'], True)
)
# Never use f-strings or % formatting for SQL — always pass values as a tuple

Node.js (mysql2)

// Using ? placeholders — mysql2 escapes automatically
const [rows] = await connection.execute(
    'SELECT * FROM users WHERE username = ? AND active = ?',
    [req.body.username, 1]
);

Java (JDBC)

PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ? AND active = ?"
);
stmt.setString(1, request.getParameter("username"));
stmt.setInt(2, 1);
ResultSet rs = stmt.executeQuery();

Defense Layer 2: ORM Usage — and Its Limits

Modern ORMs like Django ORM, Hibernate, Eloquent, and Sequelize generate parameterized queries by default. If you use the ORM API correctly, you are largely protected. The danger zones:

Raw SQL escapes within ORMs

# Django — UNSAFE: user input in raw()
User.objects.raw(f"SELECT * FROM users WHERE name = '{username}'")

# Django — SAFE: parameterized raw()
User.objects.raw("SELECT * FROM users WHERE name = %s", [username])

Laravel / Eloquent — UNSAFE

// Never interpolate into whereRaw
DB::table('users')->whereRaw("name = '{$name}'");

// SAFE — use bindings
DB::table('users')->whereRaw("name = ?", [$name]);

Sequelize (Node.js) — UNSAFE

// Never use template literals in where
User.findAll({ where: sequelize.literal(`name = '${name}'`) });

// SAFE
User.findAll({ where: { name: name } });

The rule: never interpolate or concatenate user input into any SQL string, even inside an ORM. Always use the ORM's parameterization bindings.

Defense Layer 3: Stored Procedures

Stored procedures define SQL logic on the database side. When called with parameters (not string concatenation inside the procedure), they provide parameterization at the database level:

-- MySQL stored procedure (safe)
DELIMITER $$
CREATE PROCEDURE GetUser(IN p_username VARCHAR(100))
BEGIN
    SELECT * FROM users WHERE username = p_username;
END$$

-- Calling it safely from PHP:
$stmt = $pdo->prepare('CALL GetUser(?)');
$stmt->execute([$username]);

Note: stored procedures are not a silver bullet. If the procedure itself concatenates dynamic SQL internally (e.g. uses EXECUTE IMMEDIATE with string building), the vulnerability exists inside the procedure.

Defense Layer 4: Input Validation and Allowlisting

Parameterized queries handle the SQL injection vector, but adding input validation reduces attack surface further:

Allowlist expected characters — if a field should be a numeric ID, reject anything that is not a number.
Enforce length limits — reject inputs that are too long to be legitimate.
Validate type before use — cast to integer, float, or UUID where appropriate.

// PHP — validate a numeric ID before using it
$user_id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($user_id === false || $user_id <= 0) {
    http_response_code(400);
    exit('Invalid ID');
}
// $user_id is now a safe integer — even concatenated in SQL it cannot inject

Allowlisting does not replace parameterization — column names and table names cannot be parameterized (only values can). If you must handle dynamic column/table names, allowlist them explicitly:

$allowed_columns = ['name', 'email', 'created_at'];
$sort_col = $_GET['sort'] ?? 'name';
if (!in_array($sort_col, $allowed_columns, true)) {
    $sort_col = 'name'; // fallback to safe default
}
$sql = "SELECT * FROM users ORDER BY {$sort_col} ASC"; // safe because column name is allowlisted

Defense Layer 5: Least Privilege Database Users

Even if an attacker finds an SQL injection, the blast radius depends on what the database user can do. Your application should connect as a user with only the permissions it needs:

Application role	Required permissions	Should NOT have
Web app (read/write)	SELECT, INSERT, UPDATE, DELETE on specific tables	DROP, CREATE, ALTER, FILE, SUPER, GRANT
Reporting / read-only	SELECT on specific views or tables	INSERT, UPDATE, DELETE, DDL
Migrations / admin	DDL permissions (run separately, never from app)	Should not be the runtime app user

-- MySQL: create a minimal-privilege app user
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'strong_random_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.users TO 'appuser'@'localhost';
GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.orders TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
-- No DROP, no FILE, no SUPER — limits what injection can do

Defense Layer 6: Disable Detailed Database Error Messages

Database error messages in production responses are a gift to attackers — they reveal table names, column names, query structure, and database type. This is called error-based SQLi reconnaissance.

// PHP — never expose DB errors to users in production
try {
    $stmt = $pdo->prepare($sql);
    $stmt->execute($params);
} catch (PDOException $e) {
    error_log($e->getMessage()); // log internally
    http_response_code(500);
    exit('An error occurred. Please try again later.'); // generic message only
}

Set display_errors = Off in php.ini in production. Similarly, configure your ORM to suppress raw SQL errors from HTTP responses.

Defense Layer 7: Web Application Firewall (WAF)

A WAF provides a last-resort safety net by detecting and blocking known SQL injection patterns before they reach your application. Common WAF solutions include Cloudflare WAF, AWS WAF, ModSecurity (for Apache/Nginx), and Sucuri.

WAFs are not a substitute for parameterized queries — a sufficiently obfuscated payload can bypass WAF rules. But they raise the cost of attack significantly and stop automated scanners and script-kiddies.

ModSecurity with OWASP CRS (Core Rule Set) provides a solid baseline:

# nginx + ModSecurity + OWASP CRS
# modsecurity.conf:
SecRuleEngine On
SecRequestBodyAccess On
Include /etc/nginx/modsec/crs/crs-setup.conf
Include /etc/nginx/modsec/crs/rules/*.conf

SQL Injection Prevention Checklist

✅ Use parameterized queries / prepared statements everywhere — no exceptions
✅ Set PDO::ATTR_EMULATE_PREPARES => false in PHP/PDO
✅ Never use string concatenation or interpolation to build SQL queries
✅ In ORMs, always use parameterized raw() calls — never f-string / template interpolation
✅ Allowlist dynamic column/table names — they cannot be parameterized
✅ Validate and cast input types before use (integer IDs, UUIDs, etc.)
✅ Run DB connections under least-privilege users — no DDL rights for the app user
✅ Suppress database error details in HTTP responses — log internally only
✅ Deploy a WAF with OWASP CRS rules as a defence-in-depth layer
✅ Run automated scanning (SQLMap, OWASP ZAP) against your own app regularly
✅ Set up a bug bounty or responsible disclosure policy for external researchers

Testing Your Own App for SQL Injection

Prevention is best confirmed by testing. Tools you should run against your own application in a staging environment:

SQLMap — automatic SQL injection detection and exploitation tool (use only on apps you own)
OWASP ZAP — open-source web application scanner with active SQL injection rules
Burp Suite Community — manual proxy for intercepting and modifying requests to test injection points

# SQLMap basic scan (staging/dev only — never against live production without permission)
sqlmap -u "https://staging.myapp.com/users?id=1" --dbs --batch

If any finding comes back, treat it as critical (P0) and fix immediately before it reaches production.

Want to check whether your server leaks database error messages or lacks security headers? Try our free HTTP Security Headers Analyzer — paste any URL for an instant scan. Runs entirely in your browser.

CORS Explained: Why Your API Requests Fail

Rasim Çarkçı — Sun, 11 Oct 2026 14:26:55 +0000

You fetch an API from JavaScript and get a cryptic "blocked by CORS policy" error. Nothing in your code is wrong — it's the browser enforcing a security rule. Here is exactly what CORS is, why it exists, and how to fix it.

Originally published on MoreOnlineTools Blog.

What Is CORS and Why Does It Exist?

CORS stands for Cross-Origin Resource Sharing. It is a browser security mechanism that controls how web pages load resources from a different origin (domain, protocol, or port) than the page itself.

The underlying rule CORS enforces is called the Same-Origin Policy (SOP). Browsers have applied SOP since the late 1990s: a script on https://example.com cannot by default read responses from https://api.otherdomain.com. Without this rule, any malicious website could silently fetch your bank page, read the response, and steal your account data using your already-logged-in session cookies.

CORS does not block the request itself — your browser still sends it. CORS blocks JavaScript from reading the response when the server has not explicitly said "this origin is allowed."

What Counts as a Different Origin?

Two URLs share the same origin only if all three of these match exactly:

Protocol: http vs https are different origins
Domain: example.com vs api.example.com are different origins
Port: localhost:3000 vs localhost:8080 are different origins

So https://app.example.com and https://api.example.com are cross-origin, even though they share the same root domain. Subdomains always count as different origins.

Simple Requests vs Preflight Requests

Not all cross-origin requests trigger the same CORS flow. Browsers split them into two categories:

Simple Requests

A request is "simple" if it meets all of these conditions:

Method is GET, POST, or HEAD
Only uses safe headers: Accept, Accept-Language, Content-Language, or Content-Type limited to application/x-www-form-urlencoded, multipart/form-data, or text/plain
No event listeners on XMLHttpRequestUpload

For simple requests, the browser sends the request directly and checks the response for Access-Control-Allow-Origin. If the header is missing or the origin does not match, the browser blocks JavaScript from reading the response and logs a CORS error.

Preflight Requests

Any request that is not "simple" — for example, a PUT or DELETE, a request with Authorization or Content-Type: application/json, or a custom header — triggers a preflight.

A preflight is an automatic OPTIONS request the browser sends before the actual request. The browser asks the server: "I want to send a POST with JSON and an Authorization header from this origin. Is that allowed?" The server must respond with the appropriate CORS headers. Only then does the browser proceed with the actual request.

OPTIONS /api/data HTTP/1.1
Host: api.example.com
Origin: https://app.mysite.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, Authorization

A correct server response to a preflight:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.mysite.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

Access-Control-Max-Age tells the browser how many seconds to cache the preflight result — avoiding a round-trip on every subsequent request.

The Key CORS Response Headers

Header	Purpose	Example value
`Access-Control-Allow-Origin`	Which origins may read the response	`https://app.mysite.com` or `*`
`Access-Control-Allow-Methods`	Which HTTP methods are permitted	`GET, POST, DELETE, OPTIONS`
`Access-Control-Allow-Headers`	Which request headers are permitted	`Content-Type, Authorization`
`Access-Control-Allow-Credentials`	Whether cookies/auth may be included	`true`
`Access-Control-Expose-Headers`	Which response headers JS can read	`X-Request-Id, X-RateLimit-Remaining`
`Access-Control-Max-Age`	Seconds to cache the preflight result	`86400`

The Wildcard Trap: Why `*` Is Not Always Enough

Setting Access-Control-Allow-Origin: * seems like the easiest fix — and for public read-only APIs it usually works fine. But there is one critical limitation: you cannot use * with credentials.

If your request includes cookies, HTTP authentication, or a TLS client certificate (i.e. you set credentials: "include" in fetch()), the browser requires an explicit origin, not a wildcard. The server must also explicitly set Access-Control-Allow-Credentials: true. Using * in this scenario results in a CORS error even though the header is present.

// ❌ This combination is ALWAYS rejected by the browser:
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

// ✅ Correct for credentialed requests:
Access-Control-Allow-Origin: https://app.mysite.com
Access-Control-Allow-Credentials: true

How to Fix CORS: Backend Configuration

PHP (Native)

<?php
$allowed_origins = [
    'https://app.mysite.com',
    'https://staging.mysite.com',
];
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';

if (in_array($origin, $allowed_origins, true)) {
    header("Access-Control-Allow-Origin: {$origin}");
    header('Access-Control-Allow-Credentials: true');
}

header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS');
header('Access-Control-Allow-Headers: Content-Type, Authorization');
header('Access-Control-Max-Age: 86400');

// Handle preflight
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
    http_response_code(204);
    exit;
}

Node.js / Express

const cors = require('cors');

app.use(cors({
    origin: ['https://app.mysite.com', 'https://staging.mysite.com'],
    credentials: true,
    methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
    allowedHeaders: ['Content-Type', 'Authorization'],
    maxAge: 86400,
}));

Nginx

add_header Access-Control-Allow-Origin "https://app.mysite.com" always;
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;
add_header Access-Control-Allow-Headers "Content-Type, Authorization" always;
add_header Access-Control-Allow-Credentials "true" always;

if ($request_method = OPTIONS) {
    add_header Access-Control-Max-Age 86400;
    return 204;
}

Apache (.htaccess)

Header always set Access-Control-Allow-Origin "https://app.mysite.com"
Header always set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
Header always set Access-Control-Allow-Headers "Content-Type, Authorization"
Header always set Access-Control-Allow-Credentials "true"

Multiple Allowed Origins (Dynamic Validation)

You cannot list multiple origins in a single Access-Control-Allow-Origin header — it only accepts one value or *. The correct pattern is to validate the incoming Origin header against a server-side allowlist and echo it back if it matches:

// Generic pattern (any language)
IF request.origin IN allowlist:
    response.header("Access-Control-Allow-Origin", request.origin)
    response.header("Vary", "Origin")  // Important for CDN caching
ELSE:
    response.header("Access-Control-Allow-Origin", "null")  // deny

Note the Vary: Origin header — without it, a CDN or proxy might cache a response intended for one origin and serve it to a different one.

CORS Is Not a Security Feature for the Server

This is the most common misconception about CORS. CORS does not protect your API from unauthorized access. It only controls what browsers do with responses. A curl request, a Postman request, or a server-to-server request completely ignores CORS — browsers are the only enforcement point.

If you need to restrict who can call your API, use proper authentication (JWT, API keys, OAuth) and authorization checks on the server side. CORS is for protecting users' browsers from malicious websites reading cross-site responses — not for protecting your API from unauthorized callers.

Common CORS Errors and What They Mean

Error message	Root cause	Fix
No 'Access-Control-Allow-Origin' header is present	Server never sends the header	Add the header to your server/backend
The value of 'Access-Control-Allow-Origin' is not equal to the supplied origin	Header is present but origin does not match	Use dynamic origin echo or correct whitelist
Credential flag is true, but the 'Access-Control-Allow-Credentials' header is not 'true'	Using credentials without the header	Add `Access-Control-Allow-Credentials: true` and remove wildcard
Request header field Authorization is not allowed by Access-Control-Allow-Headers	The preflight rejected the Authorization header	Add Authorization to `Access-Control-Allow-Headers`
Method PUT is not allowed by Access-Control-Allow-Methods	Method missing from the preflight response	Add the method to `Access-Control-Allow-Methods`

CORS in Local Development

During development you often hit CORS errors because your frontend runs on localhost:3000 (Vite, Create React App, etc.) while your backend runs on localhost:8000. Different ports = different origins.

The cleanest solution is to add http://localhost:3000 to your server's CORS allowlist in development mode. An alternative is to use your bundler's proxy feature:

// vite.config.js
export default {
    server: {
        proxy: {
            '/api': {
                target: 'http://localhost:8000',
                changeOrigin: true,
            }
        }
    }
}

With a dev proxy, the browser thinks all requests go to localhost:3000 — no cross-origin, no CORS. This is the approach used by most modern frontend frameworks.

Key Takeaways

CORS is enforced by browsers only — servers and tools like curl are unaffected
It restricts reading responses, not sending requests
Simple requests go through directly; non-simple requests trigger an OPTIONS preflight
Access-Control-Allow-Origin: * cannot be used together with credentials
Always echo the specific origin dynamically and include Vary: Origin when using an allowlist
CORS does not replace authentication — it is a browser-level protection for users, not an API access control mechanism

Want to check whether your server sends correct CORS and security headers? Try our free HTTP Security Headers Analyzer — paste any URL and get an instant breakdown of every header, including Access-Control-Allow-Origin. Runs entirely in your browser.

DEV Community: Rasim Çarkçı

HMAC Authentication: What It Is and How It Works

What Is HMAC?

The Two Problems HMAC Solves

The HMAC Algorithm Step by Step

Step-by-Step Walkthrough

Why Two Rounds of Hashing?

HMAC vs Other Authentication Methods

When to Use HMAC Over JWT

Webhook Signature Verification

Timing Attacks — The Hidden Danger

How Timing Attacks Work

Constant-Time Comparison by Language

Implementation Examples

PHP Implementation

Python Implementation

JavaScript / Node.js Implementation

Choosing the Right Hash Function

Common Mistakes

1. Sending the Secret in the Request

2. Not Including a Timestamp

3. Using Regular String Comparison

4. Reusing the Same Secret Across Multiple Services

5. Using a Short or Weak Secret Key

6. Verifying the Signature After Processing the Request

Real-World Examples

GitHub Webhooks

Stripe Webhooks

AWS Signature Version 4

Related Security Reads

SQL Injection Prevention: Developer's Security Checklist

Why SQL Injection Is Still Top of the OWASP List

How SQL Injection Works

Defense Layer 1: Parameterized Queries (Prepared Statements)

PHP (PDO)

PHP (MySQLi)

Python (psycopg2 / PostgreSQL)

Node.js (mysql2)

Java (JDBC)

Defense Layer 2: ORM Usage — and Its Limits

Raw SQL escapes within ORMs

Laravel / Eloquent — UNSAFE

Sequelize (Node.js) — UNSAFE

Defense Layer 3: Stored Procedures

Defense Layer 4: Input Validation and Allowlisting

Defense Layer 5: Least Privilege Database Users

Defense Layer 6: Disable Detailed Database Error Messages

Defense Layer 7: Web Application Firewall (WAF)

SQL Injection Prevention Checklist

Testing Your Own App for SQL Injection

CORS Explained: Why Your API Requests Fail

What Is CORS and Why Does It Exist?

What Counts as a Different Origin?

Simple Requests vs Preflight Requests

Simple Requests

Preflight Requests

The Key CORS Response Headers

The Wildcard Trap: Why * Is Not Always Enough

How to Fix CORS: Backend Configuration

PHP (Native)

Node.js / Express

Nginx

Apache (.htaccess)

Multiple Allowed Origins (Dynamic Validation)

CORS Is Not a Security Feature for the Server

Common CORS Errors and What They Mean

CORS in Local Development

Key Takeaways

The Wildcard Trap: Why `*` Is Not Always Enough