# PHP-frameworks in overzicht

> PHP-frameworks in overzicht: wat Laravel, Symfony, Laminas, Slim en andere bieden, hoe u kiest en wat een framework voor de beveiliging betekent.

Bron: https://phpsos.de/nl/php/php-frameworks/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Een PHP-framework is een basisraamwerk van herbruikbare code dat typische taken van een webtoepassing al oplost: verzoeken naar de juiste code doorsturen, formuliergegevens verwerken, databases aanspreken, uitvoer genereren. Bekende PHP-frameworks zijn Laravel, Symfony, Laminas, CodeIgniter, Yii, CakePHP en Slim. Een framework brengt beveiligingsbouwstenen mee, maar beschermt niet tegen lekken in de PHP-interpreter zoals PHP2Shell.

## Wat is een PHP-framework?

Zonder framework schrijft elk team routing, formuliercontrole, sessies en foutafhandeling opnieuw. Een framework geeft daarvoor vaste bouwstenen en conventies voor. Dat bespaart tijd, maakt code leesbaar voor nieuwe ontwikkelaars en bundelt beveiligingsfuncties op één plek in plaats van ze over honderden bestanden te verspreiden.

Voor de directie is vooral één gevolg belangrijk: met de keuze voor een framework bindt u zich jarenlang aan de releasecyclus ervan. Als het framework een PHP-versie niet meer ondersteunt of zelf niet meer wordt onderhouden, wordt elke update duurder.

De meeste moderne frameworks worden via [Composer](https://phpsos.de/nl/php/composer/) geïnstalleerd en houden zich aan standaarden van de PHP-FIG, zoals PSR-4 voor autoloading of PSR-7 voor HTTP-berichten.

## De bekende PHP-frameworks vergeleken

Het volgende overzicht gebruikt de zelfbeschrijvingen van de projecten op hun startpagina's. Beoordelingen naar populariteit of marktaandeel laten wij bewust weg, omdat daarvoor geen betrouwbare gemeenschappelijke bron bestaat.

| Framework | Zelfbeschrijving (vrij weergegeven) | Typische toepassing |
|---|---|---|
| Laravel | framework met „batterijen inbegrepen” voor webtoepassingen | maatwerk, portalen, SaaS |
| Symfony | krachtig framework met herbruikbare componenten | grote, langlevende toepassingen; componenten in andere projecten |
| Laminas | door de gemeenschap onderhouden voortzetting van het Zend Framework | bedrijfstoepassingen, middleware |
| CodeIgniter | klein framework met sterke functies | kleinere toepassingen, lage instapdrempel |
| Yii | framework voor snelle ontwikkeling van moderne toepassingen | webtoepassingen, basis van enkele CMS'en |
| CakePHP | framework met duidelijke MVC-conventies | klassieke databasetoepassingen |
| Slim | microframework voor webtoepassingen en API's | slanke API's, middleware-diensten |

Symfony noemt op zijn startpagina Drupal, Laravel, API Platform en Composer als projecten die Symfony-componenten gebruiken. Een framework zit dus vaak ook waar men het niet direct ziet. Hoe dat bij CMS'en en webshops eruitziet, toont de pagina [CMS'en en webshopsystemen op PHP](https://phpsos.de/nl/php/cms-und-shops-auf-php/).

## Gemeenschappelijke bouwstenen van bijna alle frameworks

Ondanks verschillende filosofie delen de meeste frameworks een opbouw. Alle verzoeken lopen via één enkel instappunt, de front controller, meestal `public/index.php`. De webserver geeft daarvoor elk adres waarvoor geen echt bestand bestaat aan dit bestand door.

```nginx
# Voorbeeld: Nginx stuurt onbekende paden naar de front controller
root /var/www/app/public;

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

Bij Apache neemt meestal een herschrijfregel in de openbare map deze taak over, bij andere webservers een vergelijkbare regel. Belangrijk is in alle gevallen dat de webserver naar de map `public` wijst en niet naar de hoofdmap van het project. Een verkeerd ingestelde documentmap hoort tot de meest voorkomende oorzaken van configuratiebestanden die plotseling openbaar opvraagbaar zijn.

Het voordeel voor de beveiliging: alleen de map `public` staat in de webroot. Configuratie, broncode en `vendor` staan een niveau erboven en zijn via URL niet bereikbaar. Daarna wijst de router het verzoek aan een controller toe, controleert middleware de aanmelding of het CSRF-token en genereert een template-engine de uitvoer met automatische escaping.

## Hoe kiest men een framework?

Voor een nieuwe ontwikkeling of de overname van een bestaand project helpen deze vragen:

1. **Onderhoud en releasecyclus:** Hoe lang worden versies van beveiligingsupdates voorzien, en zijn er versies met verlengde ondersteuning?
2. **PHP-ondersteuning:** Draait de gebruikte frameworkversie op een PHP-versie die zelf nog beveiligingsupdates krijgt? Dat staat in de vereisten van het project.
3. **Team en dienstverlener:** Kent het team het framework, en vindt u in noodgevallen vakmensen ervoor?
4. **Ecosysteem:** Zijn er onderhouden pakketten voor uw eisen, of zou veel zelf gebouwd moeten worden?
5. **Standaarden:** Houdt het framework zich aan PSR-interfaces, dan zijn bouwstenen later eenvoudiger te vervangen.

Voor Laravel- en Symfony-projecten hebben wij eigen pagina's over beveiliging: [Laravel-toepassingen beveiligen](https://phpsos.de/nl/plattformen/laravel/) en [Symfony-toepassingen beveiligen](https://phpsos.de/nl/plattformen/symfony/).

## Wat een framework voor de beveiliging doet en wat niet

Frameworks nemen ontwikkelaars veel foutbronnen uit handen: voorbereide databasequery's tegen SQL-injectie, automatische escaping tegen cross-site scripting, CSRF-bescherming voor formulieren, veilige wachtwoordhashes. Dat werkt echter alleen als het team deze bouwstenen gebruikt en niet omzeilt.

Tegen PHP2Shell helpt dat alles niet. CVE-2026-109618 en CVE-2026-109619 zitten in de PHP-interpreter. Het PHP-team schat het risico bij mod_php het hoogst in; daar is een exploit gedemonstreerd voordat er ook maar toepassingscode draait. Het framework komt dus helemaal niet aan bod. Verhelpen kan alleen de update naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 en de herstart van alle PHP-processen.

> **Belangrijk:**
> Een framework-update en een PHP-update zijn twee afzonderlijke taken. Beide horen bij het onderhoud, maar alleen de PHP-update sluit PHP2Shell.

Bij oudere projecten komt nog een risico erbij: hangt een toepassing aan een oude frameworkversie, dan hangt ze vaak ook aan een oude PHP-versie. Voor PHP 8.1 en ouder zijn er van het PHP-project geen officiële updates meer.

## Hoe helpt PHP SOS concreet?

- Wij stellen framework, versie en PHP-vereisten van uw toepassing vast en bepalen of beide nog beveiligingsupdates krijgen.
- Wij controleren de opbouw: staat alleen `public` in de webroot, zijn configuratie en `vendor` beschermd?
- Wij plannen framework- en PHP-updates afzonderlijk, testen ze en installeren ze met herstart van alle workers.
- Voor maatwerk bieden wij een [beveiligingsaudit en penetratietest](https://phpsos.de/nl/leistungen/sicherheitsaudit-penetrationstest/) aan, die het gebruik van de beschermingsfuncties van het framework gericht toetst.


## Veelgestelde vragen

**Welk PHP-framework is het beste?**  
Dat hangt af van het project. Beslissend zijn omvang en levensduur van de toepassing, de kennis in het team, het onderhoud door het project en de ondersteuning van actuele PHP-versies. Een goed onderhouden framework dat het team kent, is meestal een betere keuze dan het momenteel populairste.

**Beschermt een framework tegen PHP2Shell?**  
Nee. PHP2Shell zit in de PHP-interpreter, en volgens het PHP-team is bij mod_php een exploit gedemonstreerd voordat er ook maar toepassingscode draait. Geen enkele framework-update vervangt de update van de PHP-runtime en de herstart van alle workers.

**Wat is een microframework?**  
Een microframework levert alleen de kern, meestal routing, middleware en verzoek-antwoordobjecten. Databasetoegang, templates of formulieren kiest men er zelf bij. Slim noemt zichzelf bijvoorbeeld een microframework voor PHP.

**Wat betekent het als een CMS Symfony-componenten gebruikt?**  
Het gebruikt afzonderlijke bouwstenen van Symfony, bijvoorbeeld voor HTTP-verwerking of de console, zonder het hele framework over te nemen. Beveiligingsmeldingen over die componenten raken dan ook het CMS, wat bij de updateplanning telt.

## Bronnen

- [Symfony](https://symfony.com/)
- [Laravel](https://laravel.com/)
- [Laminas Project](https://getlaminas.org/)
- [Slim Framework](https://www.slimframework.com/)