Blocage des chemins commençant par un point
OxPHP bloque l'accès à tout chemin d'URL contenant un segment qui commence par ., en renvoyant 404 Not Found. Cela empêche l'exposition de fichiers sensibles comme .env, .git/, .htaccess, .svn/ et .DS_Store, qui sont fréquemment ciblés par les scanners automatisés.
Cette protection est toujours active et ne peut pas être désactivée. Elle s'applique à tous les modes de routage (traditionnel, framework, SPA et worker).
Ce qui est bloqué
Toute requête dont un segment de chemin commence par . renvoie 404 :
| Requête | Résultat |
|---|---|
/.env |
404 |
/.git/config |
404 |
/.htaccess |
404 |
/.DS_Store |
404 |
/.docker/config.json |
404 |
/path/.hidden/file.txt |
404 |
/path/to/.env |
404 |
Les contournements par encodage pour-cent sur un seul niveau sont également interceptés : /%2egit/HEAD se décode une fois en /.git/HEAD et est rejeté.
L'exception .well-known
La RFC 8615 définit /.well-known/ comme un emplacement standard pour les métadonnées applicables à l'ensemble d'un site. OxPHP autorise l'accès aux sous-chemins situés dans .well-known, avec certaines restrictions :
| Requête | Résultat |
|---|---|
/.well-known/security.txt |
Servi comme fichier statique |
/.well-known/acme-challenge/token |
Servi comme fichier statique (Let's Encrypt) |
/.well-known/openid-configuration |
Servi si le fichier existe, sinon repli sur ENTRY_FILE ou 404 |
/.well-known |
404 (chemin nu) |
/.well-known/ |
404 (listage de répertoire) |
/.well-known/test.php |
404 (exécution PHP bloquée) |
Les fichiers PHP situés dans .well-known ne sont jamais exécutés : ils renvoient toujours 404. Ce répertoire ne sert que du contenu statique.
Les types MIME sont déterminés d'après l'extension du fichier. Les fichiers sans extension (comme openid-configuration) sont servis en tant que application/octet-stream.
Limites
Les entrées à double encodage (/%252egit/HEAD) ne sont décodées qu'une seule fois et restent /%2egit/HEAD, ce que cette couche ne reconnaît pas comme un segment commençant par un point. Les clients HTTP et navigateurs standard ne pratiquent pas le double encodage, ce qui rend le cas rarement problématique en pratique ; si votre proxy en amont normalise les URI avant de les transmettre, un décodage en une seule passe suffit.
Voir aussi
- Routage — modes de routage et sécurité des chemins