Aktuel situation: PHP2Shell. To kritiske PHP-sårbarheder (CVSS 9,2) tillader skadelig kode uden login. Rettelser siden 21.10.2026.Hvad der skal gøres nu →

PHP-frameworks i overblik

Frameworks giver PHP-applikationer struktur, routing og sikkerhedsbyggesten. Dette overblik viser de kendte frameworks, udvælgelseskriterier og grænserne for deres beskyttelse.

Status 4 min. læsetidPHP-viden

Kort sagt: Et PHP-framework er et grundgerüst af genbrugelig kode, der allerede løser en webapplikations typiske opgaver: føre forespørgsler hen til den rigtige kode, behandle data fra formularer, tale med databaser, generere output. Kendte PHP-frameworks er Laravel, Symfony, Laminas, CodeIgniter, Yii, CakePHP og Slim. Et framework medbringer sikkerhedsbyggesten, men beskytter ikke mod sårbarheder i PHP-fortolkeren som PHP2Shell.

Hvad er et PHP-framework?

Uden framework skriver hvert team routing, formularkontrol, sessioner og fejlhåndtering på ny. Et framework giver faste byggesten og konventioner hertil. Det sparer tid, gør koden læsbar for nye udviklere og samler sikkerhedsfunktioner ét sted i stedet for at fordele dem over hundredvis af filer.

For direktionen er især én følge vigtig: Med valget af et framework binder I jer for år til dets udgivelsescyklus. Hvis frameworket ikke længere understøtter en PHP-version eller selv ikke længere vedligeholdes, bliver hver opdatering dyrere.

De fleste moderne frameworks installeres via Composer og overholder standarder fra PHP-FIG, f.eks. PSR-4 til autoloading eller PSR-7 til HTTP-meddelelser.

De kendte PHP-frameworks sammenlignet

Det følgende overblik bruger projekternes selvbeskrivelser på deres forsider. Vurderinger efter popularitet eller markedsandel udelader vi bevidst, fordi der ikke findes en pålidelig fælles kilde hertil.

Framework Selvbeskrivelse (i hovedtræk) Typisk anvendelse
Laravel framework med "batterier inkluderet" til webapplikationer egenudviklinger, portaler, SaaS
Symfony kraftfuldt framework med genbrugelige komponenter store, langlivede applikationer; komponenter i andre projekter
Laminas fællesskabsvedligeholdt videreførelse af Zend Framework virksomhedsapplikationer, middleware
CodeIgniter lille framework med stærke funktioner mindre applikationer, lav indgangstærskel
Yii framework til hurtig udvikling af moderne applikationer webapplikationer, grundlag for enkelte CMS
CakePHP framework med klare MVC-konventioner klassiske databaseapplikationer
Slim mikro-framework til webapplikationer og API'er slanke API'er, middleware-tjenester

Symfony nævner på sin forside Drupal, Laravel, API Platform og Composer som projekter, der bruger Symfony-komponenter. Et framework sidder altså ofte også dér, hvor man ikke ser det direkte. Hvordan det ser ud ved CMS og shops, viser siden CMS og shopsystemer på PHP.

Fælles byggesten i næsten alle frameworks

Trods forskellig filosofi deler de fleste frameworks en opbygning. Alle forespørgsler løber gennem ét enkelt indgangspunkt, front-controlleren, som regel public/index.php. Webserveren giver hertil hver adresse, som der ikke findes en rigtig fil til, videre til denne fil.

# Eksempel: Nginx leder ukendte stier videre til front-controlleren
root /var/www/app/public;

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

Ved Apache overtager som regel en omskrivningsregel i den offentlige mappe denne opgave, ved andre webservere en tilsvarende regel. Vigtigt er i alle tilfælde, at webserveren peger på mappen public og ikke på projektets hovedmappe. Et forkert sat dokumentbibliotek hører til de hyppigste årsager til, at konfigurationsfiler pludselig kan hentes offentligt.

Fordelen for sikkerheden: Kun mappen public ligger i webroot. Konfiguration, kildekode og vendor ligger ét niveau over og kan ikke nås via URL. Derefter overtager routeren tilordningen til en controller, middleware kontrollerer login eller CSRF-token, og en skabelonmotor genererer outputtet med automatisk maskering.

Hvordan vælger man et framework?

Ved en nyudvikling eller overtagelse af et eksisterende projekt hjælper disse spørgsmål:

  1. Vedligeholdelse og udgivelsescyklus: Hvor længe forsynes versioner med sikkerhedsopdateringer, og findes der versioner med forlænget understøttelse?
  2. PHP-understøttelse: Kører den anvendte framework-version på en PHP-version, som selv stadig får sikkerhedsopdateringer? Det står i projektets krav.
  3. Team og leverandør: Kender teamet frameworket, og kan I i nødstilfælde finde fagfolk til det?
  4. Økosystem: Findes der vedligeholdte pakker til jeres krav, eller skulle meget bygges selv?
  5. Standarder: Overholder frameworket PSR-grænseflader, kan byggesten senere udskiftes lettere.

Til Laravel- og Symfony-projekter har vi egne sider om sikring: Sikring af Laravel-applikationer og Sikring af Symfony-applikationer.

Hvad et framework leverer for sikkerheden, og hvad det ikke gør

Frameworks fjerner mange fejlkilder fra udviklerne: forberedte databaseforespørgsler mod SQL-injection, automatisk maskering mod cross-site scripting, CSRF-beskyttelse til formularer, sikre adgangskode-hashes. Det virker dog kun, hvis teamet bruger disse byggesten og ikke omgår dem.

Mod PHP2Shell hjælper alt dette ikke. CVE-2026-109618 og CVE-2026-109619 ligger i PHP-fortolkeren. PHP-teamet vurderer risikoen ved mod_php som den højeste; dér blev en exploit vist, før der overhovedet kører applikationskode. Frameworket kommer altså slet ikke i spil. Afhjælpning skaber kun opdateringen til PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 og genstarten af alle PHP-processer.

Vigtigt

En framework-opdatering og en PHP-opdatering er to adskilte opgaver. Begge hører med i vedligeholdelsen, men kun PHP-opdateringen lukker PHP2Shell.

Ved ældre projekter kommer endnu en risiko til: Hænger en applikation fast på en gammel framework-version, hænger den ofte også fast på en gammel PHP-version. Til PHP 8.1 og ældre findes der fra PHP-projektet ikke længere officielle opdateringer.

Hvordan hjælper PHP SOS konkret?

  • Vi finder jeres applikations framework, version og PHP-krav og fastslår, om begge stadig får sikkerhedsopdateringer.
  • Vi kontrollerer opbygningen: Ligger kun public i webroot, er konfiguration og vendor beskyttet?
  • Vi planlægger framework- og PHP-opdateringer hver for sig, tester dem og indspiller dem med genstart af alle workere.
  • Til egenudviklinger tilbyder vi et sikkerhedsaudit og penetrationstest, der målrettet kontrollerer brugen af frameworkets beskyttelsesfunktioner.

Ofte stillede spørgsmål

Hvilket PHP-framework er det bedste?

Det afhænger af projektet. Afgørende er applikationens størrelse og levetid, teamets know-how, projektets vedligeholdelse og understøttelsen af aktuelle PHP-versioner. Et velvedligeholdt framework, som teamet kender, er som regel et bedre valg end det lige nu mest populære.

Beskytter et framework mod PHP2Shell?

Nej. PHP2Shell ligger i PHP-fortolkeren, og ifølge PHP-teamet blev der ved mod_php vist en exploit, før der overhovedet kører applikationskode. Ingen framework-opdatering erstatter opdateringen af PHP-runtime og genstarten af alle workere.

Hvad er et mikro-framework?

Et mikro-framework leverer kun kernen, typisk routing, middleware og forespørgsel-svar-objekter. Databaseadgang, skabeloner eller formularer vælger man selv til. Slim betegner sig f.eks. selv som mikro-framework til PHP.

Hvad betyder det, når et CMS bruger Symfony-komponenter?

Det bruger enkelte byggesten fra Symfony, f.eks. til HTTP-behandling eller konsol, uden at overtage hele frameworket. Sikkerhedsmeddelelser om disse komponenter berører så også CMS'et, hvilket tæller ved opdateringsplanlægningen.

Kilder

Akut kontakt

Hver time tæller. Skriv til os nu.

Beskriv kort system, PHP-version og observation. Vi vender tilbage, afklarer situationen og arbejder på afstand, indtil hændelsen er afsluttet og dokumenteret.

Akut hjælp