PSR Standards of the PHP-FIG

In short: PSRs (PHP Standards Recommendations) are standards of the PHP-FIG, a group of established PHP projects. They define shared rules and interfaces, for example PSR-4 for autoloading, PSR-3 for loggers, PSR-7 for HTTP messages and PSR-11 for containers. Every PSR has a status: accepted, draft, deprecated or abandoned. PSRs make code more interchangeable and easier to review, but they do not close flaws in the PHP interpreter such as PHP2Shell.

What is the PHP-FIG and what are PSRs?

PHP-FIG stands for PHP Framework Interop Group. The group itself describes its goal as advancing PHP through collaboration and standards. Behind a PSR, then, there is no single vendor but an agreement between projects that want to keep their software compatible with one another.

For decision-makers the benefit is tangible: if an application adheres to PSR interfaces, the logging library, for example, can be swapped without touching the whole code. This reduces dependence on individual packages and service providers.

The path of a PSR: from pre-draft to accepted

The PHP-FIG bylaws describe a fixed process:

1. Pre-draft: It is clarified whether there is enough interest. A working group forms, and after a successful vote the proposal receives a PSR number.
2. Draft: The proposal is worked out, and alternatives and rationales go into a meta document.
3. Review: The community tests the specification with trial implementations, for at least four weeks and until two independent, viable implementations exist.
4. Accepted: After a successful vote the PSR is adopted; the working group dissolves.

There are also two further states. Deprecated means: accepted but no longer recommended, usually because a newer standard replaces it. Abandoned means: no more work is being done on it.

All PSRs with their status

Status according to the PHP-FIG overview at the time of this page:

The most important PSRs in practice

• PSR-4 (autoloading): maps class names to file paths and is the basis of the Composer autoloader. Details on the page Namespaces and autoloading.
• PSR-1 and PER Coding Style: shared rules for spelling and formatting. According to the PHP-FIG, PER Coding Style extends and replaces PSR-12 and presupposes PSR-1.
• PSR-3 (logger): a uniform logger interface in the Psr\Log namespace with eight levels from emergency to debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): interfaces for requests and responses, middleware, factories and HTTP clients. Many PHP frameworks build on them or offer bridges.
• PSR-11 (container): a shared interface for dependency injection containers.
• PSR-6 and PSR-16 (cache): two interfaces for caching, one detailed and one simple.
• PSR-14 and PSR-20 (events, clock): shared interfaces for events and for the current time. An interchangeable clock makes time-dependent code, such as the expiry of tokens, easy to test.

Incidentally, the numbers say nothing about importance. They are assigned when a proposal enters the draft phase, which is why deprecated and abandoned proposals sit between important, accepted standards.

<?php
use Psr\Log\LoggerInterface;

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

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

What PSRs have to do with security

Several standards touch on security directly. PSR-3 specifies that exceptions are passed in the context under the key exception and that placeholders such as {datei} are replaced from the context. Values are not supposed to be escaped beforehand, because the logger does not know where they will be displayed later. Anyone who displays logs in a web interface must escape them there. More on this in the article Logging safely.

PSR-7 describes HTTP messages as immutable objects and, with UploadedFileInterface::moveTo(), offers a uniform way to store uploaded files. The specification requires that the original file be removed afterwards. Checking the file type and destination remains the application's job.

It is noteworthy that PSR-9 (Security Advisories) and PSR-10 (Security Reporting Process) were abandoned. There is therefore no shared standard for security reports; each project regulates this itself. How the PHP project itself deals with vulnerabilities is described on the page How the PHP project handles security vulnerabilities.

Standards do not help against PHP2Shell: the vulnerabilities CVE-2026-109618 and CVE-2026-109619 lie in the interpreter. The update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and the restart of all PHP processes are mandatory.

How does PHP SOS help?

• We check how your application logs and make sure that exceptions end up in the log but credentials or session identifiers do not.
• We assess how upload and HTTP processing are implemented, even when they run through PSR-7 libraries.
• We examine custom developments as part of a security audit and penetration test.
• We apply PHP updates, restart all workers and document the status.

Frequently asked questions

Sources

• PHP-FIG: PSR overview
• PHP-FIG: PSR workflow
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface