Configuration, secrets et sécurité en production

La configuration d'une application PHP (adresse de la base, mot de passe, clés d'API, mode développement ou production) ne s'écrit pas dans le code : elle se lit dans des variables d'environnement ou dans un fichier .env placé hors de la racine du site et jamais versionné. Ce chapitre explique comment ranger les secrets de Prêtmat, régler PHP pour la production, gérer les erreurs sans rien révéler, limiter les droits du compte MySQL, et termine par la liste de contrôle de sécurité de toute l'application. Le cours Sécurité des applications replace ces mesures dans le Top 10 de l'OWASP (mauvaise configuration).

Ce qu'est un secret

Un secret est une information qui donne un accès : le mot de passe du compte MySQL de l'application, une clé d'API d'un service de mail, le mot de passe SMTP, une clé de chiffrement. Celui qui l'obtient agit à la place de l'application.

Lire la configuration depuis l'environnement

Les variables d'environnement sont fournies au processus PHP par le système : par compose.yaml avec Docker (chapitre 1), par la configuration d'Apache (SetEnv) ou de PHP-FPM (env[DB_PASSWORD] = …). PHP les lit avec getenv(). En développement, sans Docker, un fichier .env à la racine du projet joue ce rôle :

# Configuration locale de Prêtmat, jamais versionnée
APP_ENV=dev
DB_HOST=127.0.0.1
DB_NAME=pretmat
DB_USER=pretmat_app
DB_PASSWORD="x7!Gq#2;p=Vb"

Dans ce fichier, un commentaire commence par # et ne contient ni parenthèses ni guillemets : parse_ini_file() les refuserait. Une valeur qui contient des caractères spéciaux (#, ;, =) s'écrit entre guillemets, comme le mot de passe ci-dessus.

Une fonction de quelques lignes le charge au démarrage, sans écraser une vraie variable d'environnement :

<?php

declare(strict_types=1);

// src/bootstrap.php (début)
function chargerEnv(string $fichier): void
{
    if (!is_file($fichier)) {
        return;   // en production, les variables viennent du serveur
    }
    $valeurs = parse_ini_file($fichier, false, INI_SCANNER_RAW);
    if ($valeurs === false) {
        throw new RuntimeException("Fichier de configuration illisible : $fichier");
    }
    foreach ($valeurs as $cle => $valeur) {
        if (getenv($cle) === false) {   // une variable déjà définie par le serveur est prioritaire
            putenv("$cle=$valeur");
        }
    }
}

chargerEnv(__DIR__ . '/../.env');

Mets entre guillemets les valeurs qui contiennent des caractères spéciaux (;, #, =, espaces). La fonction bdd() du chapitre 7 lit déjà ses paramètres avec getenv() : elle fonctionne telle quelle.

Le dépôt Git contient un modèle, .env.example, avec les noms des variables et des valeurs factices, pour que chaque développeur sache quoi remplir. Le vrai .env est dans le .gitignore :

# .gitignore
.env
/vendor/
/var/log/
/var/uploads/

Le cours Git explique le fichier .gitignore, et le cours Intégration continue la gestion des secrets dans un pipeline.

php.ini en production

Le fichier php.ini-production fourni avec PHP contient déjà la plupart de ces réglages : pars de lui, et vérifie le résultat avec php -i ou une page phpinfo() que tu supprimes aussitôt (elle affiche toute la configuration, variables d'environnement comprises).

Un gestionnaire d'erreurs global

Une exception que personne n'attrape doit aboutir à une page d'erreur propre, pas à une page blanche ni à un message technique. PHP permet de déclarer un gestionnaire d'exceptions global, appelé en dernier recours :

<?php

declare(strict_types=1);

// src/bootstrap.php (suite)
$enDev = (getenv('APP_ENV') ?: 'prod') === 'dev';
ini_set('display_errors', $enDev ? '1' : '0');

// Les avertissements (variable indéfinie, clé absente…) deviennent des exceptions : rien ne passe inaperçu
set_error_handler(function (int $niveau, string $message, string $fichier, int $ligne): bool {
    if (!(error_reporting() & $niveau)) {
        return false;
    }
    throw new ErrorException($message, 0, $niveau, $fichier, $ligne);
});

set_exception_handler(function (Throwable $e) use ($enDev): void {
    error_log((string) $e);   // message, fichier, ligne et pile d'appels, dans le journal

    if (!headers_sent()) {
        http_response_code(500);
    }
    $chemin = parse_url($_SERVER['REQUEST_URI'] ?? '/', PHP_URL_PATH) ?: '/';
    if (str_starts_with($chemin, '/api/')) {
        header('Content-Type: application/problem+json');
        echo json_encode(['type' => 'about:blank', 'title' => 'Erreur interne', 'status' => 500]);
        return;
    }
    echo $enDev
        ? '<pre>' . htmlspecialchars((string) $e) . '</pre>'
        : '<h1>Une erreur est survenue</h1><p>L\'équipe a été prévenue. Réessaie dans quelques minutes.</p>';
});

En développement, tu vois l'erreur complète ; en production, l'utilisateur voit un message neutre et le détail part dans le journal. La page d'erreur de production est volontairement du HTML simple : si l'erreur vient des vues, utiliser rendre() pour l'afficher provoquerait une nouvelle erreur.

Journaliser les événements de sécurité

Le journal ne sert pas qu'aux erreurs : il garde la trace des événements de sécurité, indispensables pour détecter une attaque et comprendre un incident.

<?php

function journaliser(string $evenement, array $contexte = []): void
{
    $ligne = date(DATE_ATOM) . ' ' . $evenement;
    foreach ($contexte as $cle => $valeur) {
        $ligne .= ' ' . $cle . '=' . str_replace(["\r", "\n", ' '], '_', (string) $valeur);
    }
    error_log($ligne);
}

journaliser('acces_refuse', ['utilisateur' => 2, 'route' => 'POST /materiels/4/supprimer']);

Les retours à la ligne et les espaces d'une valeur sont remplacés : sinon, une saisie contenant un saut de ligne pourrait fabriquer une fausse ligne dans le journal (injection de journal). On ne journalise jamais un mot de passe, même faux, ni un jeton ; et comme le journal contient des données personnelles (adresses, adresses IP), on fixe sa durée de conservation (journalisation et gestion des erreurs).

Le compte MySQL de l'application

L'application se connecte avec un compte qui n'a que les droits nécessaires à son fonctionnement : lire et modifier les données, pas modifier la structure ni gérer les comptes.

CREATE USER 'pretmat_app'@'10.0.1.%' IDENTIFIED BY 'mot-de-passe-long-et-aléatoire';
GRANT SELECT, INSERT, UPDATE, DELETE ON pretmat.* TO 'pretmat_app'@'10.0.1.%';

• Pas de DROP, ALTER, CREATE ni GRANT : une injection réussie ne peut ni supprimer les tables ni créer un compte. Les évolutions de structure se font avec un autre compte, réservé aux déploiements.
• L'hôte '10.0.1.%' limite les connexions aux machines du réseau des serveurs d'application.
• On peut aller plus loin : retirer DELETE sur la table emprunt pour que l'historique ne puisse jamais être effacé par l'application.

Avec l'image Docker de MySQL, les variables MYSQL_USER et MYSQL_PASSWORD créent un compte qui a tous les droits sur la base MYSQL_DATABASE : pratique en développement, à remplacer par un compte restreint en production. Le cours SQL détaille les comptes, les rôles et les droits (GRANT et REVOKE).

HTTPS et en-têtes de sécurité

En production, l'application n'est servie qu'en HTTPS : sans chiffrement, le mot de passe et le cookie de session circulent en clair sur le réseau. Un certificat Let's Encrypt est gratuit et se renouvelle automatiquement. L'en-tête HSTS demande ensuite au navigateur de ne plus jamais utiliser HTTP pour ce site :

<?php

header('Strict-Transport-Security: max-age=31536000');   // un an

Les autres en-têtes de sécurité (CSP, X-Content-Type-Options, Referrer-Policy) sont posés par le contrôleur frontal (chapitre 12).

Mettre à jour PHP et les dépendances

Une application sûre aujourd'hui ne l'est plus dans un an si personne ne la met à jour :

• PHP : reste sur une version maintenue. PHP 8.4 reçoit des correctifs de sécurité jusqu'à fin 2028, PHP 8.5 jusqu'à fin 2029 (chapitre 1). Les versions mineures (8.5.x) s'installent sans risque.
• Les dépendances Composer : composer audit liste celles qui ont une faille connue, et composer outdated celles qui ont une nouvelle version. Lance la première dans l'intégration continue, à chaque modification (cours Intégration continue).
• MySQL et le système : les mises à jour de sécurité de la distribution, régulièrement.

La liste de contrôle de sécurité d'une application PHP

Cette liste rassemble les protections vues dans le cours. Passe ton application de l'E6 à ce crible avant de la présenter : chaque ligne est une question que la commission peut te poser.

Exercices

<?php
$pdo = new PDO('mysql:host=51.91.x.x;dbname=pretmat', 'root', 'Sorbier2026!');
ini_set('display_errors', '1');

GRANT SELECT, INSERT, UPDATE, DELETE ON pretmat.materiel TO 'pretmat_app'@'10.0.1.%';
GRANT SELECT, INSERT, UPDATE ON pretmat.emprunt TO 'pretmat_app'@'10.0.1.%';
GRANT SELECT, INSERT, UPDATE ON pretmat.utilisateur TO 'pretmat_app'@'10.0.1.%';
GRANT SELECT, INSERT, DELETE ON pretmat.echec_connexion TO 'pretmat_app'@'10.0.1.%';
GRANT SELECT, INSERT, DELETE ON pretmat.jeton_api TO 'pretmat_app'@'10.0.1.%';