PHP-FIG:n PSR-standardit

Lyhyesti: PSR:t (PHP Standards Recommendations) ovat PHP-FIG:n, vakiintuneiden PHP-hankkeiden ryhmän, standardeja. Ne määrittävät yhteisiä sääntöjä ja rajapintoja, esimerkiksi PSR-4 automaattiselle lataukselle, PSR-3 lokittajille, PSR-7 HTTP-viesteille ja PSR-11 säiliöille. Jokaisella PSR:llä on tila: hyväksytty, luonnos, vanhentunut tai hylätty. PSR:t tekevät koodista vaihdettavampaa ja helpommin tarkastettavaa, mutta ne eivät sulje PHP-tulkin aukkoja, kuten PHP2Shelliä.

Mitä PHP-FIG on ja mitä PSR:t ovat?

PHP-FIG on lyhenne sanoista PHP Framework Interop Group. Ryhmä kuvaa itse tavoitteekseen viedä PHP:tä eteenpäin yhteistyöllä ja standardeilla. PSR:n takana ei siis ole yksittäistä valmistajaa vaan hankkeiden välinen sopimus, joiden ohjelmistot halutaan pitää keskenään yhteensopivina.

Päättäjälle hyöty on konkreettinen: kun sovellus noudattaa PSR-rajapintoja, esimerkiksi lokituskirjaston voi vaihtaa koskematta koko koodiin. Se vähentää riippuvuutta yksittäisistä paketeista ja palveluntarjoajista.

PSR:n polku: Pre-Draftista Acceptediin

PHP-FIG:n säännöt kuvaavat kiinteän kulun:

1. Pre-Draft: Selvitetään, onko kiinnostusta riittävästi. Työryhmä muodostuu, ja onnistuneen äänestyksen jälkeen ehdotus saa PSR-numeron.
2. Draft: Ehdotus kehitetään, ja vaihtoehdot sekä perustelut kirjataan metadokumenttiin.
3. Review: Yhteisö testaa määrittelyä koetoteutuksilla vähintään neljän viikon ajan ja siihen asti, kunnes on olemassa kaksi toisistaan riippumatonta, kelvollista toteutusta.
4. Accepted: Onnistuneen äänestyksen jälkeen PSR on hyväksytty; työryhmä purkautuu.

Lisäksi on kaksi muuta tilaa. Deprecated tarkoittaa: hyväksytty mutta ei enää suositeltu, yleensä koska uudempi standardi korvaa sen. Abandoned tarkoittaa: sen parissa ei enää työskennellä.

Kaikki PSR:t tiloineen

Tilanne PHP-FIG:n yleiskatsauksen mukaan tämän sivun laatimishetkellä:

Käytännön tärkeimmät PSR:t

• PSR-4 (automaattinen lataus): kuvaa luokkien nimet tiedostopoluiksi ja on Composerin lataajan perusta. Yksityiskohdat sivulla Nimiavaruudet ja automaattinen lataus.
• PSR-1 ja PER Coding Style: yhteiset säännöt kirjoitusasulle ja muotoilulle. PER Coding Style laajentaa ja korvaa PHP-FIG:n mukaan PSR-12:n ja edellyttää PSR-1:n.
• PSR-3 (lokittaja): yhtenäinen lokittajarajapinta nimiavaruudessa Psr\Log kahdeksalla tasolla tasosta emergency tasoon debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): rajapinnat pyynnöille ja vastauksille, väliohjelmistoille (middleware), tehtaille ja HTTP-asiakkaille. Monet PHP-kehykset rakentuvat niiden varaan tai tarjoavat siltoja.
• PSR-11 (säiliö): yhteinen rajapinta riippuvuuksien injektointisäiliöille.
• PSR-6 ja PSR-16 (välimuisti): kaksi rajapintaa välimuistille, yksi laaja ja yksi yksinkertainen.
• PSR-14 ja PSR-20 (tapahtumat, kello): yhteiset rajapinnat tapahtumille ja nykyiselle ajalle. Vaihdettava kello tekee aikariippuvaisesta koodista, kuten tunnisteiden vanhenemisesta, hyvin testattavaa.

Numerot eivät muuten kerro mitään merkityksestä. Ne annetaan luonnosvaiheeseen siirryttäessä, ja siksi vanhentuneet ja hylätyt ehdotukset ovat tärkeiden, hyväksyttyjen standardien välissä.

<?php
use Psr\Log\LoggerInterface;

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

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

Mitä PSR:illä on tekemistä tietoturvan kanssa

Useat standardit sivuavat tietoturvaa suoraan. PSR-3 määrää, että poikkeukset annetaan kontekstissa avaimella exception ja paikkamerkit kuten {datei} korvataan kontekstista. Arvoja ei tässä tule maskata etukäteen, koska lokittaja ei tiedä, missä ne myöhemmin näytetään. Jos lokeja näytetään verkkokäyttöliittymässä, maskaus on tehtävä siellä. Lisää artikkelissa Turvallinen lokitus.

PSR-7 kuvaa HTTP-viestit muuttumattomina olioina ja tarjoaa metodilla UploadedFileInterface::moveTo() yhtenäisen tavan tallentaa ladatut tiedostot. Määrittely vaatii, että alkuperäinen tiedosto on sen jälkeen poistettu. Tiedostotyypin ja kohdepaikan tarkistus jää sovelluksen tehtäväksi.

Huomionarvoista on, että PSR-9 (Security Advisories) ja PSR-10 (Security Reporting Process) on hylätty. Yhteistä standardia tietoturvailmoituksille ei siis ole; jokainen hanke sopii asiasta itse. Miten PHP-hanke itse käsittelee aukkoja, kuvaa sivu Miten PHP-hanke käsittelee tietoturva-aukot.

PHP2Shelliä vastaan standardit eivät auta: haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 sijaitsevat tulkissa. Pakollista on päivittää versioon PHP 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 ja käynnistää kaikki PHP-prosessit uudelleen.

Miten PHP SOS auttaa konkreettisesti?

• Tarkistamme, miten sovelluksenne kirjaa lokia, ja varmistamme, että poikkeukset päätyvät lokiin mutta tunnukset tai istuntotunnisteet eivät.
• Arvioimme, miten latausten ja HTTP-viestien käsittely on toteutettu, myös silloin kun se kulkee PSR-7-kirjastojen kautta.
• Tutkimme omat kehitystyöt tietoturvatarkastuksen ja tunkeutumistestin puitteissa.
• Asennamme PHP-päivitykset, käynnistämme kaikki worker-prosessit uudelleen ja dokumentoimme tilanteen.

Usein kysytyt kysymykset

Lähteet

• PHP-FIG: PSR-yleiskatsaus
• PHP-FIG: PSR-työnkulku
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface