Em resumo: Um framework PHP é uma estrutura de código reutilizável que já resolve tarefas típicas de uma aplicação web: encaminhar pedidos para o código certo, processar dados de formulários, aceder a bases de dados, gerar saídas. Frameworks PHP conhecidos são Laravel, Symfony, Laminas, CodeIgniter, Yii, CakePHP e Slim. Um framework traz componentes de segurança, mas não protege contra falhas no interpretador PHP como o PHP2Shell.
O que é um framework PHP?
Sem framework, cada equipa escreve de novo o encaminhamento, a validação de formulários, as sessões e o tratamento de erros. Um framework fornece para isso componentes e convenções fixos. Poupa tempo, torna o código legível para novos programadores e concentra as funções de segurança num só lugar, em vez de as espalhar por centenas de ficheiros.
Para a gerência, importa sobretudo uma consequência: com a escolha de um framework, fica preso durante anos ao seu ciclo de lançamentos. Se o framework deixa de suportar uma versão do PHP ou ele próprio deixa de ser mantido, cada atualização fica mais cara.
A maioria dos frameworks modernos é instalada através do Composer e segue padrões da PHP-FIG, por exemplo o PSR-4 para o autoloading ou o PSR-7 para mensagens HTTP.
Os frameworks PHP conhecidos em comparação
O resumo seguinte usa as autodescrições dos projetos nas suas páginas iniciais. Deixamos deliberadamente de fora classificações por popularidade ou quota de mercado, porque não existe uma fonte comum fiável para isso.
| Framework | Autodescrição (em sentido aproximado) | Utilização típica |
|---|---|---|
| Laravel | framework «com baterias incluídas» para aplicações web | desenvolvimentos próprios, portais, SaaS |
| Symfony | framework de alto desempenho com componentes reutilizáveis | aplicações grandes e duradouras; componentes noutros projetos |
| Laminas | continuação do Zend Framework mantida pela comunidade | aplicações empresariais, middleware |
| CodeIgniter | framework pequeno com funcionalidades poderosas | aplicações mais pequenas, barreira de entrada baixa |
| Yii | framework para o desenvolvimento rápido de aplicações modernas | aplicações web, base de alguns CMS |
| CakePHP | framework com convenções MVC claras | aplicações clássicas de bases de dados |
| Slim | micro-framework para aplicações web e APIs | APIs enxutas, serviços de middleware |
O Symfony menciona na sua página inicial o Drupal, o Laravel, a API Platform e o Composer como projetos que utilizam componentes do Symfony. Um framework está assim muitas vezes presente também onde não se vê diretamente. Como isso se passa em CMS e lojas mostra-o a página CMS e sistemas de loja em PHP.
Componentes comuns a quase todos os frameworks
Apesar de filosofias diferentes, a maioria dos frameworks partilha uma estrutura. Todos os pedidos passam por um único ponto de entrada, o front controller, em geral public/index.php. O servidor web passa-lhe para isso cada endereço para o qual não existe um ficheiro real.
# Exemplo: o Nginx encaminha caminhos desconhecidos para o front controller
root /var/www/app/public;
location / {
try_files $uri /index.php$is_args$args;
}
No Apache, esta tarefa costuma ser assumida por uma regra de reescrita na pasta pública; noutros servidores web, por uma regra equivalente. Importante em todos os casos é que o servidor web aponte para a pasta public e não para a pasta principal do projeto. Uma pasta de documentos mal definida é uma das causas mais frequentes de ficheiros de configuração ficarem subitamente acessíveis ao público.
A vantagem para a segurança: só a pasta public está na raiz web. Configuração, código-fonte e vendor ficam um nível acima e não são acessíveis por URL. Depois, o router faz a atribuição a um controller, o middleware verifica a autenticação ou o token CSRF e um motor de templates gera a saída com escape automático.
Como escolher um framework?
Para um novo desenvolvimento ou a assunção de um projeto existente, ajudam estas perguntas:
- Manutenção e ciclo de lançamentos: Durante quanto tempo as versões recebem atualizações de segurança e existem versões com suporte prolongado?
- Suporte de PHP: A versão do framework em uso corre numa versão do PHP que ainda recebe atualizações de segurança? Isso consta dos requisitos do projeto.
- Equipa e prestadores: A equipa conhece o framework e, numa emergência, encontra-se especialistas para ele?
- Ecossistema: Existem pacotes mantidos para os seus requisitos, ou seria preciso construir muita coisa por conta própria?
- Padrões: Se o framework segue as interfaces PSR, os componentes são mais fáceis de substituir mais tarde.
Para projetos Laravel e Symfony temos páginas próprias sobre proteção: Proteger aplicações Laravel e Proteger aplicações Symfony.
O que um framework faz pela segurança e o que não faz
Os frameworks retiram aos programadores muitas fontes de erros: consultas preparadas à base de dados contra SQL injection, escape automático contra cross-site scripting, proteção CSRF para formulários, hashes de palavras-passe seguros. Mas isso só funciona se a equipa utilizar estes componentes e não os contornar.
Contra o PHP2Shell, nada disto ajuda. O CVE-2026-109618 e o CVE-2026-109619 estão no interpretador PHP. A equipa do PHP classifica o risco como o mais elevado no mod_php; aí foi demonstrado um exploit antes de qualquer código de aplicação correr. O framework nem sequer entra em ação. Só resolve a atualização para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e o reinício de todos os processos PHP.
Uma atualização do framework e uma atualização do PHP são duas tarefas separadas. Ambas pertencem à manutenção, mas só a atualização do PHP fecha o PHP2Shell.
Em projetos mais antigos acresce outro risco: se uma aplicação está presa a uma versão antiga do framework, está muitas vezes também presa a uma versão antiga do PHP. Para o PHP 8.1 e anteriores, o projeto PHP já não disponibiliza atualizações oficiais.
Como ajuda concretamente a PHP SOS?
- Apuramos o framework, a versão e os requisitos de PHP da sua aplicação e verificamos se ambos ainda recebem atualizações de segurança.
- Verificamos a estrutura: só a
publicestá na raiz web, a configuração e avendorestão protegidas? - Planeamos as atualizações do framework e do PHP em separado, testamo-las e aplicamo-las com reinício de todos os workers.
- Para desenvolvimentos próprios, oferecemos uma auditoria de segurança e teste de intrusão que verifica de forma dirigida a utilização das funções de proteção do framework.
Perguntas frequentes
Qual é o melhor framework PHP?
Depende do projeto. Contam o tamanho e a duração da aplicação, o conhecimento da equipa, a manutenção pelo projeto e o suporte de versões atuais do PHP. Um framework bem mantido e conhecido da equipa é em regra uma escolha melhor do que o mais popular do momento.
Um framework protege contra o PHP2Shell?
Não. O PHP2Shell está no interpretador PHP e, segundo a equipa do PHP, foi demonstrado no mod_php um exploit antes de qualquer código de aplicação correr. Nenhuma atualização de framework substitui a atualização do ambiente de execução PHP e o reinício de todos os workers.
O que é um micro-framework?
Um micro-framework fornece apenas o núcleo, tipicamente encaminhamento, middleware e objetos de pedido e resposta. O acesso a bases de dados, templates ou formulários escolhe-se à parte. O Slim, por exemplo, descreve-se a si próprio como micro-framework para PHP.
O que significa um CMS usar componentes do Symfony?
Utiliza componentes isolados do Symfony, por exemplo para o tratamento de HTTP ou para a consola, sem adotar o framework inteiro. Os comunicados de segurança sobre esses componentes afetam então também o CMS, o que conta no planeamento de atualizações.