Padrões PSR da PHP-FIG

Em resumo: Os PSR (PHP Standards Recommendations) são padrões da PHP-FIG, um grupo de projetos PHP consolidados. Definem regras e interfaces comuns, por exemplo o PSR-4 para o autoloading, o PSR-3 para loggers, o PSR-7 para mensagens HTTP e o PSR-11 para contentores. Cada PSR tem um estado: aceite, rascunho, obsoleto ou abandonado. Os PSR tornam o código mais substituível e mais fácil de verificar, mas não fecham vulnerabilidades do interpretador PHP como o PHP2Shell.

O que é a PHP-FIG e o que são os PSR?

PHP-FIG significa PHP Framework Interop Group. O próprio grupo descreve o seu objetivo como fazer avançar o PHP através da colaboração e de padrões. Por trás de um PSR não está, portanto, um fabricante, mas um acordo entre projetos que querem manter o seu software compatível entre si.

Para quem decide, o benefício é palpável: se uma aplicação respeitar as interfaces PSR, é possível trocar, por exemplo, a biblioteca de registo sem mexer em todo o código. Isso reduz a dependência de pacotes e prestadores de serviços individuais.

O percurso de um PSR: do pre-draft ao accepted

Os estatutos da PHP-FIG descrevem um processo fixo:

1. Pre-Draft: esclarece-se se existe interesse suficiente. Forma-se um grupo de trabalho e, após uma votação bem-sucedida, a proposta recebe um número PSR.
2. Draft: a proposta é elaborada, e as alternativas e justificações vão para um meta-documento.
3. Review: a comunidade testa a especificação com implementações de teste, durante pelo menos quatro semanas e até existirem duas implementações independentes e viáveis.
4. Accepted: após uma votação bem-sucedida, o PSR é aprovado; o grupo de trabalho dissolve-se.

Existem ainda dois outros estados. Deprecated significa: aprovado, mas já não recomendado, normalmente porque um padrão mais recente o substitui. Abandoned significa: já não se trabalha nele.

Todos os PSR com o seu estado

Estado segundo a visão geral da PHP-FIG à data desta página:

Os PSR mais importantes na prática

• PSR-4 (autoloading): mapeia nomes de classe para caminhos de ficheiro e é a base do autoloader do Composer. Detalhes na página Espaços de nomes e autoloading.
• PSR-1 e PER Coding Style: regras comuns de grafia e formatação. O PER Coding Style estende e substitui, segundo a PHP-FIG, o PSR-12 e pressupõe o PSR-1.
• PSR-3 (logger): interface de logger uniforme no espaço de nomes Psr\Log, com oito níveis, de emergency a debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): interfaces para pedidos e respostas, middleware, fábricas e clientes HTTP. Muitas frameworks PHP assentam nelas ou oferecem pontes.
• PSR-11 (contentor): interface comum para contentores de injeção de dependências.
• PSR-6 e PSR-16 (cache): duas interfaces para memórias intermédias, uma detalhada e uma simples.
• PSR-14 e PSR-20 (eventos, relógio): interfaces comuns para eventos e para a hora atual. Um relógio substituível torna o código dependente do tempo, por exemplo a expiração de tokens, bem testável.

Os números, aliás, nada dizem sobre a importância. São atribuídos na entrada na fase de rascunho, por isso há propostas obsoletas e abandonadas entre padrões importantes e aceites.

<?php
use Psr\Log\LoggerInterface;

final class Bestellimport
{
    public function __construct(private LoggerInterface $log) {}

    public function importieren(string $datei): void
    {
        try {
            // ... processar o ficheiro ...
        } catch (\Throwable $e) {
            $this->log->error('Import von {datei} fehlgeschlagen', [
                'datei'     => basename($datei),
                'exception' => $e,
            ]);
        }
    }
}

O que os PSR têm a ver com a segurança

Vários padrões tocam diretamente na segurança. O PSR-3 estabelece que as exceções são passadas no contexto com a chave exception e que marcadores como {datei} são substituídos a partir do contexto. Os valores não devem ser escapados de antemão, porque o logger não sabe onde serão apresentados mais tarde. Quem mostra registos numa interface web tem de os escapar aí. Mais sobre isto no artigo Registar em segurança.

O PSR-7 descreve as mensagens HTTP como objetos imutáveis e oferece, com UploadedFileInterface::moveTo(), um caminho uniforme para guardar ficheiros enviados. A especificação exige que o ficheiro original seja removido depois. A verificação do tipo de ficheiro e do destino continua a ser tarefa da aplicação.

É de notar que o PSR-9 (Security Advisories) e o PSR-10 (Security Reporting Process) foram abandonados. Não existe, portanto, um padrão comum para comunicações de segurança; cada projeto regula-o por si. Como o próprio projeto PHP lida com vulnerabilidades descreve-o a página Como o projeto PHP trata as vulnerabilidades de segurança.

Contra o PHP2Shell, os padrões não ajudam: as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 estão no interpretador. É obrigatória a atualização para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e o reinício de todos os processos PHP.

Como ajuda concretamente a PHP SOS?

• Verificamos como a sua aplicação regista eventos e garantimos que as exceções vão para o registo, mas sem dados de acesso nem identificadores de sessão.
• Avaliamos como estão implementados o processamento de uploads e de HTTP, mesmo quando passam por bibliotecas PSR-7.
• Examinamos desenvolvimentos próprios no âmbito de uma auditoria de segurança e teste de intrusão.
• Aplicamos atualizações do PHP, reiniciamos todos os workers e documentamos o estado.

Perguntas frequentes

Fontes

• PHP-FIG: visão geral dos PSR
• PHP-FIG: fluxo de trabalho dos PSR
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface