Bonjour,
Puisqu’OVH continue à identifier à tort des sites « hackés » dans le cache de SPIP, voici l’idée :
dans config/mes_options.php
define('_NO_CACHE', -1);
Et comme ça, pas de cache, pas de détection par OVH.
C’est néanmoins crade car ça ralentit le site.
Une piste à explorer pour limiter l’impact performance : ne faire ce define que si la page demandée est celle de résultat de recherche ?
Qu’en pensez-vous ?
Quelque chose comme :
if (isset($_GET['page']) && $_GET['page'] === 'recherche') {
define('_NO_CACHE', -1);
}
marcimat
(Matthieu Marcillaud)
Août 27, 2026, 8:23
3
C’est totalement insuffisant de chercher ‹ recherche › …
On va voir ce qu’on va pouvoir faire dans une prochaine version pour limiter ces éléments en cache
3 « J'aime »
Qu’est-ce qui est stocké de problématique exactement dans le cache ?
Jack31
(Jack31)
Août 27, 2026, 10:26
5
Du code php avec du base64_decode par exemple, suite à des tentatives d’attaque. En 4.4.21 elles sont bloquées mais OVH considère que ce sont des malwares.
fix: eviter de générer du cache avec des contextex empoisonnés par du PHP (!324) · Requêtes de fusion · spip / ecrire · GitLab va règler tout ça merci la team !
2 « J'aime »
En attendant, j’ai ajouté ceci dans le .htaccess :
# Bloque les tentatives d'injection de code PHP dans la query string
RewriteCond %{QUERY_STRING} (%3C%3Fphp|<\?php|<%3fphp) [NC,OR]
RewriteCond %{QUERY_STRING} (base64_decode|file_put_contents|system\(|shell_exec|passthru|popen|eval\() [NC]
RewriteRule .* - [F,L]
3 « J'aime »
epilibre
(Gilles Vincent)
Août 30, 2026, 8:17
7
Belle config !
Pour nginx j’ai mis l’équivalent :
# Bloque les tentatives d'injection de code PHP dans la query string
if ($query_string ~* "(%3c%3fphp|<\?php|<%3fphp|base64_decode|file_put_contents|system\(|shell_exec|passthru|popen|eval\()") {
return 403;
}
2 « J'aime »