# Padrões PSR da PHP-FIG

> Padrões PSR da PHP-FIG: todos os PSR do 0 ao 22 com estado, os mais importantes na prática e o que o PSR-3, o PSR-4 e o PSR-7 significam para a segurança.

Fonte: https://phpsos.de/pt/php/psr-standards/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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:

| N.º | Título | Estado |
|---|---|---|
| PSR-0 | Autoloading Standard | obsoleto |
| PSR-1 | Basic Coding Standard | aceite |
| PSR-2 | Coding Style Guide | obsoleto |
| PSR-3 | Logger Interface | aceite |
| PSR-4 | Autoloading Standard | aceite |
| PSR-5 | PHPDoc Standard | rascunho |
| PSR-6 | Caching Interface | aceite |
| PSR-7 | HTTP Message Interface | aceite |
| PSR-8 | Huggable Interface | abandonado |
| PSR-9 | Security Advisories | abandonado |
| PSR-10 | Security Reporting Process | abandonado |
| PSR-11 | Container Interface | aceite |
| PSR-12 | Extended Coding Style Guide | aceite |
| PSR-13 | Hypermedia Links | aceite |
| PSR-14 | Event Dispatcher | aceite |
| PSR-15 | HTTP Handlers | aceite |
| PSR-16 | Simple Cache | aceite |
| PSR-17 | HTTP Factories | aceite |
| PSR-18 | HTTP Client | aceite |
| PSR-19 | PHPDoc tags | rascunho |
| PSR-20 | Clock | aceite |
| PSR-21 | Internationalization | rascunho |
| PSR-22 | Application Tracing | rascunho |

## 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](https://phpsos.de/pt/php/namespaces-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](https://phpsos.de/pt/php/php-frameworks/) 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
<?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](https://phpsos.de/pt/blog/sicher-loggen-php/).

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](https://phpsos.de/pt/php/php-sicherheitsprozess/).

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](https://phpsos.de/pt/leistungen/sicherheitsaudit-penetrationstest/).
- Aplicamos atualizações do PHP, reiniciamos todos os workers e documentamos o estado.


## Perguntas frequentes

**O que significa PSR?**  
PSR significa PHP Standards Recommendation. As recomendações são elaboradas e aprovadas pela PHP-FIG, a PHP Framework Interop Group. São voluntárias, mas são implementadas por muitas frameworks e bibliotecas.

**O PSR-12 ainda é válido?**  
O PSR-12 continua a constar como aceite na PHP-FIG. A PHP-FIG publicou, porém, com o PER Coding Style, um sucessor que, segundo a própria, estende e substitui o PSR-12. Atualmente está aí na versão 3.1.

**Existe um PSR para avisos de segurança?**  
Houve duas propostas: o PSR-9 para security advisories e o PSR-10 para o processo de comunicação de vulnerabilidades. Ambas constam na PHP-FIG como abandonadas. Os projetos regulam por isso, eles próprios, o seu processo de comunicação.

**O meu projeto tem de cumprir os PSR?**  
Não, não há obrigação. O PSR-4 para o autoloading e interfaces como o PSR-3 ou o PSR-7 facilitam, porém, bastante a utilização de pacotes alheios e a mudança de prestadores de serviços.

## Fontes

- [PHP-FIG: visão geral dos PSR](https://www.php-fig.org/psr/)
- [PHP-FIG: fluxo de trabalho dos PSR](https://www.php-fig.org/bylaws/psr-workflow/)
- [PHP-FIG: PER Coding Style](https://www.php-fig.org/per/coding-style/)
- [PHP-FIG: PSR-3 Logger Interface](https://www.php-fig.org/psr/psr-3/)
- [PHP-FIG: PSR-7 HTTP Message Interface](https://www.php-fig.org/psr/psr-7/)