Bonjour à tous et à toutes,
Ma config :
Serveur dédié, Ubuntu 20.04, Apache 2, modsecurity
Mon problème est dans la configuration d'un VirtualHost pour intégrer une directive Content-Security-Policy frame-ancestors
J'ai donc un premier serveur VirtualHost qui héberge la page cible
Un second serveur appelé LeServeurAutorisé qui a une iframe qui prend sa src sur VirtualHost.
J'ai donc intégré, dans le conf du VirtualHost, la ligne :
Header set Content-Security-Policy "frame-ancestors 'self' 'LeDomaineAutorisé';"
La page à intégrer, appelée en directe depuis le VirtualHost, s'affiche bien.
La même page à intégrer, appelée depuis LeDomaineAutorisé dans une iframe, ne s'affiche pas.
Dans la log apache, j'ai la ligne :
ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/usr/share/modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "516"] [id "920280"] [msg "Request Missing a Host Header"]
Et là !! je ne sais pas interpréter et donc résoudre le pb.
Serveurs dédiés - Configuration Apache pour intégration CSP frame-ancestors
Related questions
- Proxmox VM accès internet impossible
55156 
19.11.2016 12:11
- Spam et IP bloquée
52517 12.12.2016 11:53
- il y a quelqu'un ?
51624 15.12.2025 17:01
- Mise en place de VM avec IP publique sur Proxmox 6 [RESOLU]
50449 30.04.2020 17:12
- SSD NVMe Soft Raid ou SSD SATA Hard Raid
50099 29.06.2021 23:29
- Port 25 bloqué pour spam à répétition
47282 28.02.2018 13:39
- Mise à jour PHP sur Release 3 ovh
46782 11.03.2017 17:43
- Identification carte réseau
45591 05.12.2025 10:09
- Connection smtp qui ne marche plus : connect error 10060
45005 12.04.2019 10:10
- Partition sur le disque de l'OS ESXI
44730 09.05.2017 14:33
Bonjour,
C'est apparemment lié au parefeu (à désactiver dans Hébergement > multisite)
ce parefeu mod_security est parfois un peu trop parano.
Mais l'incrustation de sites dans un iframe, ça passe de moins en moins bien , et surtout maintenant avec https partout qui garantit qu'un ste est authentique.
Bonsoir,
Merci pour cette réponse.
J'ai oublié de préciser que c'est avec des serveurs dédiés.
Le iFrame, c'est notre client qui a ça, donc je dois faire avec.
Le blocage vient de modsecurity mais la doc semble indiquer qu'il manque des headers mais je ne sais pas trop desquels ils parlent.
Tout change, et si le site que vous tentez d'inscruster dans un iframe a décidé de ne pas l'autoriser, vous pouvez danser sur votre tête (et votre client sur la sienne)
Voyez la directive http: X-Frame-Options
_Adding an X-Frame-Options options header via the .htaccess file:_
_`Header set X-Frame-Options SAMEORIGIN`_
_Adding an X-Frame-Options options header in your PHP code_
_`_`header('X-Frame-Options: SAMEORIGIN');`_
_`?>`_
_The above header prevents your website from being loaded in iframes on other websites but can be loaded in other pages within the same domains._
_The SAMEORIGIN option allows the page to be embedded in an iframe only if the parent page is from the same domain, which presumably is also your code._
_SAMEORIGIN option can be replaced with DENY, which prevents browsers from loading the page in an iframe regardless of the domain name of the parent page._
Bonjour Fritz2cat, et merci pour votre réponse.
La iframe est chez le client. Je ne suis qu'un fournisseur de contenu.
Il m'est spécifiquement demandé la directive frame-ancestors (il semble que le X-Frame-Options n'est plus supporté par les navigateurs récents au profit de la directive frame-ancestors).
En faisant des tests, ce n'est pas uniquement sur des iframes que le frame-ancestors agit mais plus globalement sur les appels de l'url depuis des pages extérieures.
Evidemment, le blocage est visiblement sur modSecurity que je ne souhaite pas retirer car, s'il a parfois des faux-positifs, il fait quand même pas mal le job (à moins de ne retirer que ce filtre 920280 dans le fichier de config de modSecurity).
Je vais continuer les tests.
En fait vous en connaissez probablement plus que beaucoup de monde ici.