OWASP Top 10 for PHP Developers 2026

By Kokil Thapa | Last reviewed: September 2026

OWASP Top 10 for PHP Developers 2026 is not a compliance checkbox. It is a ranked list of the failures that actually burn production PHP apps — broken access control, injection, misconfiguration, and weak auth on sites that handle payments, legal documents, and customer data. PHP 8.5, Laravel 13.x, and Symfony 8.1 give you strong primitives, but they do not stop you from wiring them wrong. This guide maps each OWASP category to concrete PHP patterns, with code you can paste into a Laravel OWASP hardening workflow or a legacy WordPress plugin tomorrow morning.

What is the OWASP Top 10 and why does it matter for PHP in 2026?

The OWASP Top 10 is a community-backed ranking of the most exploited web application weaknesses. It is not a PHP standard, but PHP dominates the CMS and SME web stack — WordPress 7.1, WooCommerce 11.1, Magento 2.4.x, and thousands of custom Laravel 13.x apps — so the same ten categories appear again and again in breach post-mortems.

PHP's shared-hosting history left bad habits in the ecosystem. Developers still concatenate SQL, store passwords in plain MD5, and trust $_GET['role']. Modern runtimes fixed type coercion and removed dangerous defaults, yet application logic remains your job. Treat the Top 10 as a design review checklist before every release, not a pen-test report you file once.

On legal-tech portals and client document systems I have shipped, A01 and A07 dominate incident reports. A user changes an ID in the URL and downloads another client's file. That is not a PHP bug. It is missing authorization. The Top 10 tells you where to look first.

How do you prevent broken access control in PHP and Laravel?

A01 Broken Access Control stays at number one because developers confuse authentication with authorization. Logging in proves identity. It does not prove you may delete invoice #8842. Every controller action, API route, and AJAX endpoint needs an explicit permission check on the server.

Laravel policies and middleware

In Laravel 13.x, use Policies and route middleware. Never rely on hiding buttons in Blade.

<?php
// app/Policies/DocumentPolicy.php
public function download(User $user, Document $document): bool
{
    return $user->id === $document->user_id
        || $user->hasRole('admin');
}

// routes/web.php
Route::get('/documents/{document}/download', [DocumentController::class, 'download'])
    ->middleware(['auth', 'can:download,document']);

Register policies in AuthServiceProvider. Call $this->authorize('download', $document) inside the controller as a belt-and-braces check. For API routes protected by Sanctum, apply the same policy via Gate::authorize before streaming files from storage.

Symfony voters and attributes

Symfony 8.1 uses the #[IsGranted] attribute or custom Voters. Centralize role logic instead of scattering if ($user->getRole() === 'ADMIN') across controllers.

Common PHP access-control mistakes

• Using predictable sequential IDs without ownership checks on direct object references
• Checking roles only in the view layer while the API endpoint stays open
• Storing admin flags in JWT claims the client can decode but not verify server-side
• Missing authorization on file download routes that guess paths from user input

On a production Laravel application with document sharing, I enforce policy checks in the controller, the Form Request, and the queued export job. Background workers have no HTTP session — pass the acting user ID explicitly and re-check permissions inside the job.

How do you stop SQL injection and XSS in PHP applications?

A03 Injection covers SQL, NoSQL, OS command, and LDAP injection. PHP's historic mysql_* functions encouraged string concatenation. PDO and Eloquent exist precisely to kill that pattern. XSS is injection into HTML output — equally common, often ignored in admin panels.

Prepared statements with PDO

<?php
$stmt = $pdo->prepare('SELECT id, title FROM posts WHERE slug = :slug LIMIT 1');
$stmt->execute(['slug' => $_GET['slug']]);
$post = $stmt->fetch(PDO::FETCH_ASSOC);

Never interpolate user input into SQL strings. Not even once. Not for "safe" internal tools. Use bound parameters for values. Use an allowlist when dynamic column or table names are unavoidable — map user input to fixed strings in PHP, never pass raw identifiers to the query.

Laravel Eloquent and query builder

Eloquent parameterizes by default when you use the query builder correctly:

Post::where('slug', $request->string('slug'))->firstOrFail();

Avoid DB::raw() with concatenated input. For full-text search, use database-native bindings or Laravel's whereFullText where supported on MySQL 9.7 or PostgreSQL 18.

Output encoding against XSS

Escape on output, not on input. In Blade, {{ $name }} auto-escapes. Use {!! !!} only for trusted HTML sanitized through a library like HTML Purifier. Set Content-Security-Policy headers at the web server or middleware layer to limit inline script damage if escaping fails somewhere.

Command injection appears when PHP calls shell utilities with user input. Avoid exec(), shell_exec(), and passthru() on untrusted data. If you must run CLI tools, use escapeshellarg() and strict allowlists. Test edge cases with the regex tester when building input validators — but never substitute regex alone for parameterized queries.

Read the dedicated piece on PHP serialization vulnerabilities if your app uses unserialize() on cookies or cache payloads. That is object injection, not SQL injection, and it is equally lethal.

What security misconfiguration mistakes do PHP teams make on production servers?

A05 Security Misconfiguration covers debug modes left on, directory listing, default credentials, missing security headers, and exposed .env files. PHP-FPM and Apache/Nginx misconfiguration causes more production leaks than exotic zero-days.

Production php.ini hardening

On Ubuntu servers running PHP 8.5 via PHP-FPM, verify these settings in production pools:

expose_php = Off
display_errors = Off
log_errors = On
allow_url_include = Off
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Lax

Set APP_DEBUG=false in Laravel and APP_ENV=prod in Symfony. A stack trace leaking database credentials is a misconfiguration incident, not an application bug. Follow the Ubuntu server setup guide for PHP apps and lock down file permissions: web user owns storage/ and bootstrap/cache/, nothing else world-writable.

Web server rules

Block HTTP access to sensitive paths:

# Nginx — deny .env, vendor, git
location ~ /\.(env|git) { deny all; }
location ~ ^/(vendor|storage/logs)/ { deny all; }

Disable directory indexes. Force HTTPS with HSTS after confirming TLS works. Add security headers: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and a sensible CSP. Compare Apache versus Nginx header injection in the Nginx vs Apache for PHP article if you run mixed stacks.

Composer and dependency exposure

Run composer audit with Composer 2.10 in CI. Pin versions in composer.lock and commit it. A06 Vulnerable and Outdated Components is the OWASP category that tracks known CVEs in Symfony, Laravel, and WordPress plugins. Schedule monthly dependency updates on business-critical systems — budget Rs 15,000–25,000/month (~USD 110–185) for maintenance if you cannot staff it in-house, and route that work through support and maintenance if needed.

Linux system administration work and application security overlap here. Wrong ownership on storage/ after Deployer 7 symlink swaps has caused writable web roots on sites I maintain. Automate post-deploy permission checks in your pipeline.

How should PHP developers handle authentication, cryptography, and session security?

A02 Cryptographic Failures and A07 Identification and Authentication Failures cover weak hashing, hard-coded keys, session fixation, missing MFA on admin panels, and password reset flows that leak tokens.

Password hashing in PHP 8.5

Use password_hash() with PASSWORD_ARGON2ID (or PASSWORD_BCRYPT where Argon2 is unavailable). Laravel's Hash facade wraps this correctly. Never store reversible encryption for passwords. Never use MD5 or SHA1 for credentials.

<?php
$hash = password_hash($plainPassword, PASSWORD_ARGON2ID);
if (password_verify($inputPassword, $storedHash)) {
    session_regenerate_id(true);
}

Call session_regenerate_id(true) after login to mitigate session fixation. Laravel does this via Auth::login(). Set session lifetime conservatively on client portals — thirty minutes of inactivity logout is reasonable for legal document systems.

Encryption and secrets management

Store API keys in .env, never in Git. Use Laravel's encrypt() for sensitive database columns when you must retrieve plaintext (OAuth refresh tokens). Use application-level encryption keys rotated via APP_KEY — document rotation procedures before you need them.

Generate strong random secrets with a proper CSPRNG. The password generator tool helps developers create test credentials locally. Production secrets belong in environment variables or a vault, not Slack messages.

Multi-factor authentication and rate limiting

Throttle login routes. Laravel's RateLimiter or the throttle middleware on /login blocks brute force. Add TOTP MFA for admin and staff accounts on any app handling payments or personal data. For APIs, use short-lived tokens via Sanctum or Passport and scope abilities narrowly.

Review API security and the OWASP API Top 10 when mobile apps or SPA frontends consume your Laravel backend. Browser session auth and token auth fail in different ways.

How do you implement logging, SSRF protection, and secure design in PHP?

The remaining Top 10 categories — Insecure Design, Software and Data Integrity Failures, Security Logging and Monitoring Failures, and SSRF — often get skipped because they lack a single Composer package fix.

Security logging that actually helps

Log authentication failures, authorization denials, password reset requests, and admin actions. Send logs to a centralized sink — not only storage/logs/laravel.log on the app server. Structure JSON logs with request ID, user ID, IP, and action. Alert on spikes: fifty failed logins in five minutes means someone is knocking.

Never log passwords, full credit card numbers, or bearer tokens. Redact PII where regulations require it. On PostgreSQL 18 or MySQL 9.7 backends, log slow queries separately from security events to keep signal clean.

SSRF prevention

A10 Server-Side Request Forgery hits PHP apps that fetch remote URLs from user input — webhooks, "import from URL" features, PDF generators. Block private IP ranges, localhost, and cloud metadata endpoints (169.254.169.254). Use an allowlist of domains when possible. Disable allow_url_fopen if you do not need it.

<?php
function isSafeRemoteUrl(string $url): bool
{
    $host = parse_url($url, PHP_URL_HOST);
    if (!$host || in_array($host, ['localhost', '127.0.0.1'], true)) {
        return false;
    }
    $ip = gethostbyname($host);
    return filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) !== false;
}

Insecure design and integrity failures

A04 Insecure Design means fixing symptoms without fixing workflows — like rate-limiting login but allowing unlimited password reset emails. Threat-model critical flows before coding: registration, checkout, document upload, role elevation. A08 Software and Data Integrity Failures covers unsigned webhooks, unverified Composer packages, and CI pipelines that deploy without checksum validation.

Verify webhook signatures from payment gateways — eSewa, Khalti, Stripe — before updating order status. On eCommerce systems, a forged callback creates real financial loss. Use idempotency keys on payment endpoints.

WordPress and WooCommerce shops face the same categories through a plugin lens. Disable file editing in wp-admin, restrict upload MIME types, keep plugins updated, and use application passwords with scoped capabilities instead of sharing the main admin password. See broader 2026 trends in cybersecurity trends for developers.

What is a practical OWASP Top 10 checklist before shipping a PHP app?

Run this list on every release candidate. It takes thirty minutes once your pipeline exists. Longer on the first pass.

1. Confirm APP_DEBUG is false and error display is off in php.ini
2. Verify every mutating route has auth plus authorization (policy or voter)
3. Grep for DB::raw, whereRaw, and string-concat SQL — eliminate or justify each hit
4. Run composer audit and resolve critical advisories
5. Confirm .env, vendor/, and log directories are not web-accessible
6. Test password reset, registration, and login for rate limits and token expiry
7. Validate webhook endpoints reject unsigned or replayed payloads
8. Check TLS, HSTS, CSP, and cookie flags on staging that mirrors production
9. Confirm security events log to a monitored channel, not only local disk
10. Run a focused penetration test or OWASP ZAP scan against staging before major launches

Fold this into testing and optimization engagements. Automated PHPUnit coverage does not prove an attacker cannot download another user's invoice. Add authorization tests explicitly:

public function test_guest_cannot_download_others_document(): void
{
    $owner = User::factory()->create();
    $stranger = User::factory()->create();
    $doc = Document::factory()->for($owner)->create();

    $this->actingAs($stranger)
        ->get(route('documents.download', $doc))
        ->assertForbidden();
}

On client portals like Mijar Law Associates, document ACL bugs are severity-one. Write tests for every role boundary you define in Spatie Laravel Permission or Symfony roles.

For greenfield work, bake this checklist into enterprise application development and custom software development scopes from day one. Retrofitting auth on a three-year-old CodeIgniter app costs more than building policies correctly in Laravel 13.x at the start.

PHP developers building APIs should pair this guide with API development standards — versioning, pagination, and rate limits are part of the attack surface. Database choice matters too: refer to the PostgreSQL for Laravel developers guide for row-level security patterns when multi-tenant isolation must sit at the database layer.

The official PHP security manual remains the baseline reference for native functions. Cross-check framework abstractions against it when you are unsure what happens under the hood.

Key Takeaways

• Broken access control is the top OWASP risk — authorize every action server-side with Laravel Policies or Symfony Voters, not hidden UI elements.
• Stop injection with PDO prepared statements, Eloquent parameter binding, and Blade output escaping — never concatenate user input into SQL or raw HTML.
• Harden production with APP_DEBUG=false, blocked .env access, security headers, and weekly composer audit runs in CI.
• Use password_hash() with Argon2id, regenerate sessions on login, throttle auth routes, and add MFA on admin accounts.
• Log security events centrally, redact secrets from logs, and validate webhook signatures before updating orders or document status.
• Run the ten-point pre-ship checklist and write authorization PHPUnit tests for every sensitive route before each production deploy.

People Also Ask

Does Laravel protect against OWASP Top 10 automatically?

Partially. Laravel 13.x provides Eloquent parameterization, CSRF middleware, encryption helpers, and policy authorization — but only if you use them consistently. Misconfigured APP_DEBUG, missing policies, or raw queries bypass framework protections instantly. Framework defaults reduce risk; they do not replace security design.

Is PHP 8.5 secure enough for production in 2026?

PHP 8.5 removed unsafe legacy behaviors and ships improved type safety and randomness APIs. Security still depends on application code, dependency hygiene, and server configuration. Running unsupported PHP 7.x or unpatched 8.x builds is the bigger danger — stay on supported releases and apply distro security patches monthly.

How often should PHP teams run dependency audits?

Run composer audit on every CI build and review results weekly. Critical CVEs should trigger an emergency patch within forty-eight hours on internet-facing apps. Schedule planned minor version bumps monthly for active products handling payments or personal data.

What is the difference between OWASP Top 10 and OWASP API Top 10?

The classic OWASP Top 10 covers general web applications — browser sessions, server-rendered forms, file uploads. The OWASP API Security Top 10 targets JSON endpoints, JWT misuse, excessive data exposure, and broken object-level authorization in microservices. PHP Laravel apps often need both checklists when they serve Blade frontends and mobile APIs.

Build secure PHP applications with OWASP as your baseline

The OWASP Top 10 for PHP Developers 2026 is the shortest path from "we should be secure" to concrete defences you can code this week. Start with access control and injection on your highest-risk routes — document downloads, payment callbacks, admin panels — then harden configuration and logging before the next deploy. If you want an experienced hand on architecture review or hardening an existing Laravel, Symfony, or WordPress codebase, contact us or browse the portfolio for examples of production systems built with security baked in from the first sprint. Read more on the blog, review the about page, or explore web development services when you are ready to scope the work.