Standardele PSR ale PHP-FIG

Pe scurt: PSR-urile (PHP Standards Recommendations) sunt standarde ale PHP-FIG, un grup de proiecte PHP consacrate. Ele stabilesc reguli și interfețe comune, de exemplu PSR-4 pentru autoloading, PSR-3 pentru loggere, PSR-7 pentru mesaje HTTP și PSR-11 pentru containere. Fiecare PSR are o stare: acceptat, ciornă, depășit sau abandonat. PSR-urile fac codul mai ușor de înlocuit și de verificat, dar nu închid vulnerabilități din interpretorul PHP, precum PHP2Shell.

Ce este PHP-FIG și ce sunt PSR-urile?

PHP-FIG înseamnă PHP Framework Interop Group. Grupul își descrie singur scopul ca fiind promovarea PHP prin cooperare și standarde. În spatele unui PSR nu se află deci un producător, ci un acord între proiecte care vor să-și păstreze software-ul compatibil între ele.

Pentru factorii de decizie, beneficiul este concret: dacă o aplicație respectă interfețele PSR, biblioteca de logare poate fi înlocuită, de exemplu, fără a atinge întregul cod. Aceasta reduce dependența de pachete și de prestatori individuali.

Drumul unui PSR: de la Pre-Draft la Accepted

Statutul PHP-FIG descrie un parcurs fix:

1. Pre-Draft: se clarifică dacă există suficient interes. Se formează un grup de lucru, iar după un vot reușit propunerea primește un număr PSR.
2. Draft: propunerea este elaborată, iar alternativele și motivările intră într-un meta-document.
3. Review: comunitatea testează specificația cu implementări de probă, cel puțin patru săptămâni și până când există două implementări independente, viabile.
4. Accepted: după un vot reușit, PSR-ul este adoptat; grupul de lucru se dizolvă.

Pe lângă acestea există alte două stări. Deprecated înseamnă: acceptat, dar nemaifiind recomandat, de obicei fiindcă un standard mai nou îl înlocuiește. Abandoned înseamnă: nu se mai lucrează la el.

Toate PSR-urile cu starea lor

Starea potrivit prezentării generale a PHP-FIG la momentul acestei pagini:

Cele mai importante PSR-uri pentru practică

• PSR-4 (autoloading): asociază numele de clase cu căi de fișiere și este baza autoloaderului Composer. Detalii pe pagina Namespace-uri și autoloading.
• PSR-1 și PER Coding Style: reguli comune pentru scriere și formatare. PER Coding Style extinde și înlocuiește, potrivit PHP-FIG, PSR-12 și presupune PSR-1.
• PSR-3 (logger): interfață unitară de logger în namespace-ul Psr\Log, cu opt niveluri, de la emergency la debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): interfețe pentru cereri și răspunsuri, middleware, fabrici și clienți HTTP. Multe framework-uri PHP se construiesc pe ele sau oferă punți către ele.
• PSR-11 (container): interfață comună pentru containerele de dependency injection.
• PSR-6 și PSR-16 (cache): două interfețe pentru memorii intermediare, una detaliată și una simplă.
• PSR-14 și PSR-20 (evenimente, ceas): interfețe comune pentru evenimente și pentru ora curentă. Un ceas înlocuibil face codul dependent de timp, de exemplu expirarea token-urilor, ușor de testat.

Numerele nu spun, de altfel, nimic despre importanță. Ele sunt atribuite la intrarea în faza de ciornă, de aceea propunerile depășite și cele abandonate se află între standarde importante, acceptate.

<?php
use Psr\Log\LoggerInterface;

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

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

Ce legătură au PSR-urile cu securitatea

Mai multe standarde ating direct securitatea. PSR-3 stabilește că excepțiile se transmit în context sub cheia exception, iar substituenții precum {datei} sunt înlocuiți din context. Valorile nu trebuie să fie mascate în prealabil, deoarece loggerul nu știe unde vor fi afișate ulterior. Cine afișează loguri într-o interfață web trebuie să le maseze acolo. Mai multe în articolul Logare sigură.

PSR-7 descrie mesajele HTTP ca obiecte imuabile și oferă, cu UploadedFileInterface::moveTo(), o cale unitară de a salva fișierele încărcate. Specificația cere ca fișierul original să fie îndepărtat după aceea. Verificarea tipului de fișier și a locului de destinație rămâne sarcina aplicației.

Demn de remarcat este că PSR-9 (Security Advisories) și PSR-10 (Security Reporting Process) au fost abandonate. Nu există deci un standard comun pentru raportările de securitate; fiecare proiect le reglementează singur. Cum tratează proiectul PHP însuși vulnerabilitățile descrie pagina Cum tratează proiectul PHP vulnerabilitățile de securitate.

Împotriva PHP2Shell, standardele nu ajută: vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 se află în interpretor. Obligatorii sunt actualizarea la PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 și repornirea tuturor proceselor PHP.

Cum ajută PHP SOS concret?

• Verificăm cum loghează aplicația dumneavoastră și ne asigurăm că excepțiile ajung în log, dar nu și datele de acces sau identificatorii de sesiune.
• Evaluăm cum sunt implementate procesarea upload-urilor și cea HTTP, chiar dacă rulează prin biblioteci PSR-7.
• Examinăm dezvoltările proprii în cadrul unui audit de securitate și test de penetrare.
• Instalăm actualizările PHP, repornim toți workerii și documentăm starea.

Întrebări frecvente

Surse

• PHP-FIG: privire de ansamblu asupra PSR-urilor
• PHP-FIG: fluxul de lucru PSR
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface