PHP Frameworks at a Glance

In short: A PHP framework is a foundation of reusable code that already solves typical tasks of a web application: routing requests to the right code, processing form data, talking to databases, generating output. Well-known PHP frameworks are Laravel, Symfony, Laminas, CodeIgniter, Yii, CakePHP and Slim. A framework brings security building blocks but does not protect against flaws in the PHP interpreter such as PHP2Shell.

What is a PHP framework?

Without a framework, every team rewrites routing, form validation, sessions and error handling. A framework provides fixed building blocks and conventions for this. That saves time, makes code readable for new developers and bundles security functions in one place instead of spreading them over hundreds of files.

For management, one consequence matters above all: by choosing a framework you tie yourself to its release cycle for years. If the framework no longer supports a PHP version or is itself no longer maintained, every update becomes more expensive.

Most modern frameworks are installed via Composer and follow PHP-FIG standards, such as PSR-4 for autoloading or PSR-7 for HTTP messages.

The well-known PHP frameworks compared

The following overview uses the projects' own descriptions on their home pages. We deliberately leave out rankings by popularity or market share because there is no reliable common source for them.

On its home page, Symfony names Drupal, Laravel, API Platform and Composer as projects that use Symfony components. A framework is therefore often present even where you do not see it directly. What this looks like for CMS and shops is shown on the page CMS and shop systems on PHP.

Shared building blocks of almost all frameworks

Despite different philosophies, most frameworks share a structure. All requests run through a single entry point, the front controller, usually public/index.php. For this, the web server passes every address for which there is no real file on to this file.

# Example: Nginx forwards unknown paths to the front controller
root /var/www/app/public;

location / {
    try_files $uri /index.php$is_args$args;
}

With Apache, this task is usually handled by a rewrite rule in the public folder, with other web servers by a comparable rule. In all cases it is important that the web server points to the public folder and not to the project's main directory. A wrongly set document root is among the most common reasons why configuration files suddenly become publicly retrievable.

The advantage for security: only the public folder sits in the web root. Configuration, source code and vendor sit one level above and cannot be reached via URL. After that, the router maps the request to a controller, middleware checks login or CSRF tokens, and a template engine generates the output with automatic escaping.

How do you choose a framework?

For a new development or the takeover of an existing project, these questions help:

1. Maintenance and release cycle: How long do versions receive security updates, and are there versions with extended support?
2. PHP support: Does the framework version in use run on a PHP version that itself still receives security updates? This is stated in the project's requirements.
3. Team and service providers: Does the team know the framework, and can you find experts for it in an emergency?
4. Ecosystem: Are there maintained packages for your requirements, or would a lot have to be built in-house?
5. Standards: If the framework follows PSR interfaces, building blocks can be swapped more easily later.

For Laravel and Symfony projects we have dedicated pages on securing them: Securing Laravel applications and Securing Symfony applications.

What a framework does for security and what it does not

Frameworks relieve developers of many sources of error: prepared database queries against SQL injection, automatic escaping against cross-site scripting, CSRF protection for forms, secure password hashes. But this only works if the team uses these building blocks and does not bypass them.

None of this helps against PHP2Shell. CVE-2026-109618 and CVE-2026-109619 lie in the PHP interpreter. The PHP team rates the risk highest for mod_php; an exploit was demonstrated there before any application code runs. The framework therefore never comes into play. The only remedy is the update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and the restart of all PHP processes.

With older projects there is a further risk: if an application is stuck on an old framework version, it is often stuck on an old PHP version too. For PHP 8.1 and older there are no more official updates from the PHP project.

How does PHP SOS help?

• We determine the framework, version and PHP requirements of your application and establish whether both still receive security updates.
• We check the structure: is only public in the web root, and are configuration and vendor protected?
• We plan framework and PHP updates separately, test them and install them with a restart of all workers.
• For custom developments we offer a security audit and penetration test that specifically checks the use of the framework's protective functions.

Frequently asked questions

Sources

• Symfony
• Laravel
• Laminas Project
• Slim Framework