<!DOCTYPE html SYSTEM "about:legacy-compat">
<html lang="fr"><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta content="width=device-width, initial-scale=1" name="viewport">
<!--
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              This file is generated from xml source: DO NOT EDIT
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      -->
<title>Conseils sur la s&eacute;curit&eacute; - Serveur HTTP Apache Version 2.4</title>
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet">
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size">
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css"><link rel="stylesheet" type="text/css" href="../style/css/prettify.css">
<script src="../style/scripts/prettify.min.js">
</script>

<link href="../images/favicon.png" rel="shortcut icon"></head>
<body id="manual-page"><div id="page-header">
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="https://cwiki.apache.org/confluence/display/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a> | <a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2">Signaler un bug</a></p>
<p class="apache">Serveur HTTP Apache Version 2.4</p>
<img alt="" src="../images/feather.png"></div>
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif"></a></div>
<div id="path">
<a href="https://www.apache.org/">Apache</a> &gt; <a href="https://httpd.apache.org/">Serveur HTTP</a> &gt; <a href="https://httpd.apache.org/docs/">Documentation</a> &gt; <a href="../">Version 2.4</a> &gt; <a href="./">Documentations diverses</a></div><div id="page-content"><div id="preamble"><h1>Conseils sur la s&eacute;curit&eacute;</h1>
<button aria-label="Toggle language list" class="lang-toggle"><svg xmlns="http://www.w3.org/2000/svg" stroke-width="2" stroke="currentColor" fill="none" viewBox="0 0 24 24" height="16" width="16"><circle r="10" cy="12" cx="12"/><line y2="12" x2="22" y1="12" x1="2"/><path d="M12 2a15.3 15.3 0 0 1 4 10 15.3 15.3 0 0 1-4 10 15.3 15.3 0 0 1-4-10 15.3 15.3 0 0 1 4-10z"/></svg></button>
<div class="toplang">
<p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
<a href="../fr/misc/security_tips.html" title="Fran&ccedil;ais">&nbsp;fr&nbsp;</a> |
<a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
<a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="T&uuml;rk&ccedil;e">&nbsp;tr&nbsp;</a></p>
</div>

    <p>Ce document propose quelques conseils et astuces concernant les
    probl&egrave;mes de s&eacute;curit&eacute; li&eacute;s
    &agrave; l'installation d'un serveur web. Certaines suggestions seront &agrave; caract&egrave;re
    g&eacute;n&eacute;ral, tandis que d'autres seront sp&eacute;cifiques &agrave; Apache.</p>
  </div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif"> <a href="#uptodate">Maintenez votre serveur &agrave; jour</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#dos">Attaques de type "D&eacute;ni de service"
    (Denial of Service - DoS)</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#serverroot">Permissions sur les r&eacute;pertoires de la racine du serveur</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#ssi">Inclusions c&ocirc;t&eacute; serveur</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#cgi">Les CGI en g&eacute;n&eacute;ral</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#nsaliasedcgi">CGI sans alias de script</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#saliasedcgi">CGI avec alias de script</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#dynamic">Autres sources de contenu dynamique</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#dynamicsec">S&eacute;curit&eacute; des contenus dynamiques</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#systemsettings">Protection de la configuration du syst&egrave;me</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#protectserverfiles">Protection par d&eacute;faut des fichiers du serveur</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#watchyourlogs">Surveillez vos journaux</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#merging">Fusion des sections de configuration</a></li>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="uptodate">Maintenez votre serveur &agrave; jour <a title="Lien permanent" href="#uptodate" class="permalink">&para;</a></h2>

    <p>Le serveur HTTP Apache a une bonne r&eacute;putation en mati&egrave;re de s&eacute;curit&eacute;
    et poss&egrave;de une communaut&eacute; de d&eacute;veloppeurs tr&egrave;s sensibilis&eacute;s aux probl&egrave;mes
    de s&eacute;curit&eacute;. Mais il est in&eacute;vitable de trouver certains probl&egrave;mes
    -- petits ou grands -- une fois le logiciel mis &agrave; disposition. C'est pour
    cette raison qu'il est crucial de se tenir inform&eacute; des mises &agrave; jour. Si
    vous avez obtenu votre version du serveur HTTP directement depuis Apache,
    nous vous conseillons grandement de vous abonner &agrave; la <a href="http://httpd.apache.org/lists.html#http-announce">Liste de diffusion
    des annonces du serveur HTTP</a> qui vous informera de
    la parution des nouvelles versions et des mises &agrave; jour de s&eacute;curit&eacute;. La
    plupart des distributeurs tiers d'Apache fournissent des services
    similaires.</p>

    <p>Gardez cependant &agrave; l'esprit que lorsqu'un serveur web est compromis, le
    code du serveur HTTP n'est la plupart du temps pas en cause. Les probl&egrave;mes
    proviennent plut&ocirc;t de code ajout&eacute;, de scripts CGI, ou du syst&egrave;me
    d'exploitation sous-jacent. Vous devez donc vous tenir inform&eacute; des
    probl&egrave;mes et mises &agrave; jour concernant tous les logiciels pr&eacute;sents sur
    votre syst&egrave;me.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="dos">Attaques de type "D&eacute;ni de service"
    (Denial of Service - DoS) <a title="Lien permanent" href="#dos" class="permalink">&para;</a></h2>

    

    <p>Tous les services r&eacute;seau peuvent faire l'objet d'attaques de type
    "D&eacute;ni de service" qui tentent de les emp&ecirc;cher de r&eacute;pondre aux clients en
    saturant leurs ressources. Il est impossible de se pr&eacute;munir totalement
    contre ce type d'attaques, mais vous pouvez accomplir certaines actions
    afin de minimiser les probl&egrave;mes qu'elles cr&eacute;ent.</p>

    <p>Souvent, l'outil anti-DoS le plus efficace sera constitu&eacute; par le
    pare-feu ou certaines configurations du syst&egrave;me d'exploitation. Par
    exemple, la plupart des pare-feu peuvent &ecirc;tre configur&eacute;s de fa&ccedil;on &agrave;
    limiter le nombre de connexions simultan&eacute;es depuis une adresse IP ou un
    r&eacute;seau, ce qui permet de pr&eacute;venir toute une gamme d'attaques simples.
    Bien s&ucirc;r, ceci n'est d'aucun secours contre les attaques de type
    "D&eacute;ni de service" distribu&eacute;es (DDoS).</p>

    <p>Certains r&eacute;glages de la configuration d'Apache peuvent aussi
    minimiser les probl&egrave;mes :</p>

    <ul>
      <li>La directive <code class="directive"><a href="../mod/mod_reqtimeout.html#requestreadtimeout">RequestReadTimeout</a></code> permet de
      limiter le temps que met le client pour envoyer sa requ&ecirc;te.</li>

      <li>La valeur de la directive
      <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code> doit &ecirc;tre diminu&eacute;e sur les
      sites sujets aux attaques DoS. Une valeur de quelques secondes devrait
      convenir. Cependant, comme <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code>
      est actuellement concern&eacute; par de nombreuses op&eacute;rations diff&eacute;rentes, lui
      attribuer une valeur trop faible peut provoquer des probl&egrave;mes avec les
      scripts CGI qui pr&eacute;sentent un long temps de r&eacute;ponse.</li>

      <li>La valeur de la directive
      <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> doit aussi &ecirc;tre
      diminu&eacute;e sur les sites sujets aux attaques DoS. Certains sites
      d&eacute;sactivent m&ecirc;me compl&egrave;tement le "maintien en vie" (keepalives)
      &agrave; l'aide de la directive
      <code class="directive"><a href="../mod/core.html#keepalive">KeepAlive</a></code>, ce qui bien s&ucirc;r
      pr&eacute;sente des inconv&eacute;nients en mati&egrave;re de performances.</li>

      <li>Les valeurs des diff&eacute;rentes directives fournies par d'autres modules
      et en rapport avec des d&eacute;lais doivent aussi &ecirc;tre v&eacute;rifi&eacute;es.</li>

      <li>Les directives
      <code class="directive"><a href="../mod/core.html#limitrequestbody">LimitRequestBody</a></code>,
      <code class="directive"><a href="../mod/core.html#limitrequestfields">LimitRequestFields</a></code>,
      <code class="directive"><a href="../mod/core.html#limitrequestfieldsize">LimitRequestFieldSize</a></code>,
      <code class="directive"><a href="../mod/core.html#limitrequestline">LimitRequestLine</a></code>, et
      <code class="directive"><a href="../mod/core.html#limitxmlrequestbody">LimitXMLRequestBody</a></code> doivent &ecirc;tre
      configur&eacute;es avec prudence afin de limiter la consommation de ressources
      induite par les demandes des clients.
      </li>

      <li>Sur les syst&egrave;mes d'exploitation qui le supportent, assurez-vous que
      la directive <code class="directive"><a href="../mod/core.html#acceptfilter">AcceptFilter</a></code> est
      activ&eacute;e afin de d&eacute;l&eacute;guer une partie du traitement des requ&ecirc;tes au
      syst&egrave;me d'exploitation. Elle est activ&eacute;e par d&eacute;faut dans le d&eacute;mon httpd
      d'Apache, mais peut n&eacute;cessiter une reconfiguration de votre noyau.</li>

      <li>Optimisez la directive <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> de fa&ccedil;on &agrave; d&eacute;finir le nombre
      maximum de connexions simultan&eacute;es au dessus duquel les ressources
      s'&eacute;puisent. Voir aussi la <a href="perf-tuning.html">documentation sur l'optimisation des
      performances</a>.</li>

      <li>L'utilisation d'un <a href="../mpm.html">module mpm</a> thread&eacute;
      vous permet de traiter d'avantage de connexions simultan&eacute;es, ce qui
      minimise l'effet des attaques DoS. Dans le futur, le module mpm
      <code class="module"><a href="../mod/event.html">event</a></code> utilisera un traitement asynchrone afin de ne pas
      d&eacute;dier un thread &agrave; chaque connexion.</li>

      <li>Il existe de nombreux modules tiers qui peuvent restreindre les
      comportements de certains clients et ainsi minimiser les probl&egrave;mes de
      DoS.</li>

    </ul>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="serverroot">Permissions sur les r&eacute;pertoires de la racine du serveur <a title="Lien permanent" href="#serverroot" class="permalink">&para;</a></h2>

    

    <p>Typiquement, Apache est d&eacute;marr&eacute; par l'utilisateur root, puis il devient
    la propri&eacute;t&eacute; de l'utilisateur d&eacute;fini par la directive <code class="directive"><a href="../mod/mod_unixd.html#user">User</a></code> afin de r&eacute;pondre aux demandes. Comme
    pour toutes les commandes ex&eacute;cut&eacute;es par root, vous devez vous assurer
    qu'elle n'est pas modifiable par les utilisateurs autres que root. Les
    fichiers eux-m&ecirc;mes, mais aussi les r&eacute;pertoires ainsi que leurs parents ne
    doivent &ecirc;tre modifiables que par root. Par exemple, si vous avez choisi de
    placer la racine du serveur dans <code>/usr/local/apache</code>, il est conseill&eacute; de
    cr&eacute;er le r&eacute;pertoire en tant que root, avec des commandes du style :</p>

    <div class="example"><p><code>
      mkdir /usr/local/apache <br>
      cd /usr/local/apache <br>
      mkdir bin conf logs <br>
      chown 0 . bin conf logs <br>
      chgrp 0 . bin conf logs <br>
      chmod 755 . bin conf logs
    </code></p></div>

    <p>Nous supposerons que <code>/</code>, <code>/usr</code> et
    <code>/usr/local</code> ne sont modifiables que par
    root. Quand vous installez l'ex&eacute;cutable <code class="program"><a href="../programs/httpd.html">httpd</a></code>, vous
    devez vous assurer qu'il poss&egrave;de des protections similaires :</p>

    <div class="example"><p><code>
      cp httpd /usr/local/apache/bin <br>
      chown 0 /usr/local/apache/bin/httpd <br>
      chgrp 0 /usr/local/apache/bin/httpd <br>
      chmod 511 /usr/local/apache/bin/httpd
    </code></p></div>

    <p>Vous pouvez cr&eacute;er un sous-r&eacute;pertoire htdocs modifiable par d'autres
    utilisateurs -- car root ne cr&eacute;e ni ex&eacute;cute aucun fichier dans ce
    sous-r&eacute;pertoire.</p>

    <p>Si vous permettez &agrave; des utilisateurs non root de modifier des fichiers
    que root &eacute;crit ou ex&eacute;cute, vous exposez votre syst&egrave;me &agrave; une compromission
    de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire
    <code class="program"><a href="../programs/httpd.html">httpd</a></code> de fa&ccedil;on &agrave; ce que la prochaine fois que vous le
    red&eacute;marrerez, il ex&eacute;cutera un code arbitraire. Si le r&eacute;pertoire des
    journaux a les droits en &eacute;criture (pour un utilisateur non root), quelqu'un
    pourrait remplacer un fichier journal par un lien symbolique vers un autre
    fichier syst&egrave;me, et root pourrait alors &eacute;craser ce fichier avec des donn&eacute;es
    arbitraires. Si les fichiers journaux eux-m&ecirc;mes ont des droits en
    &eacute;criture (pour un utilisateur non root), quelqu'un pourrait
    modifier les journaux eux-m&ecirc;mes avec des donn&eacute;es fausses.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="ssi">Inclusions c&ocirc;t&eacute; serveur <a title="Lien permanent" href="#ssi" class="permalink">&para;</a></h2>

    

    <p>Les inclusions c&ocirc;t&eacute; serveur (Server Side Includes - SSI) exposent
    l'administrateur du serveur &agrave; de nombreux risques potentiels en mati&egrave;re de
    s&eacute;curit&eacute;.</p>

    <p>Le premier risque est l'augmentation de la charge du serveur. Tous les
    fichiers o&ugrave; SSI est activ&eacute; doivent &ecirc;tre analys&eacute;s par Apache, qu'ils
    contiennent des directives SSI ou non. L'augmentation de la charge induite
    est minime, mais peut devenir significative dans le contexte d'un
    serveur partag&eacute;.</p>

    <p>Les fichiers SSI pr&eacute;sentent les m&ecirc;mes risques que les scripts CGI en
    g&eacute;n&eacute;ral. Les fichiers o&ugrave; SSI est activ&eacute; peuvent ex&eacute;cuter tout script CGI
    ou autre programme &agrave; l'aide de la commande <code>"exec cmd"</code> avec les permissions
    des utilisateur et groupe sous lesquels Apache s'ex&eacute;cute, comme d&eacute;fini
    dans <code>httpd.conf</code>.</p>

    <p>Des m&eacute;thodes existent pour am&eacute;liorer la s&eacute;curit&eacute; des fichiers SSI, tout
    en tirant parti des b&eacute;n&eacute;fices qu'ils apportent.</p>

    <p>Pour limiter les dommages qu'un fichier SSI agressif pourrait causer,
    l'administrateur du serveur peut activer<a href="../suexec.html">suexec</a>
    comme d&eacute;crit dans la section <a href="#cgi">Les CGI en g&eacute;n&eacute;ral</a>.</p>

    <p>L'activation des SSI pour des fichiers poss&eacute;dant des extensions
    <code>.html</code> ou
    <code>.htm</code> peut s'av&eacute;rer dangereux. Ceci est particuli&egrave;rement vrai dans un
    environnement de serveur partag&eacute; ou &eacute;tant le si&egrave;ge d'un traffic &eacute;lev&eacute;. Les
    fichiers o&ugrave; SSI est activ&eacute; doivent poss&eacute;der une extension sp&eacute;cifique, telle
    que la conventionnelle <code>.shtml</code>. Ceci permet de limiter la charge du serveur
    &agrave; un niveau minimum et de simplifier la gestion des risques.</p>

    <p>Une autre solution consiste &agrave; interdire l'ex&eacute;cution de scripts et
    programmes &agrave; partir de pages SSI. Pour ce faire, remplacez
    <code>Includes</code> par <code>IncludesNOEXEC</code> dans la directive
    <code class="directive"><a href="../mod/core.html#options">Options</a></code>. Notez que les utilisateurs
    pourront encore utiliser <code>&lt;--#include virtual="..." --&gt;</code> pour ex&eacute;cuter
    des scripts CGI si ces scripts sont situ&eacute;s dans des r&eacute;pertoires sp&eacute;cifi&eacute;s
    par une directive
    <code class="directive"><a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a></code>.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="cgi">Les CGI en g&eacute;n&eacute;ral <a title="Lien permanent" href="#cgi" class="permalink">&para;</a></h2>

    

    <p>Tout d'abord, vous devez toujours garder &agrave; l'esprit que vous devez
    faire confiance aux d&eacute;veloppeurs de scripts ou programmes CGI ainsi qu'&agrave;
    vos comp&eacute;tences pour d&eacute;celer les trous de s&eacute;curit&eacute; potentiels dans les
    CGI, que ceux-ci soient d&eacute;lib&eacute;r&eacute;s ou accidentels. Les scripts CGI peuvent
    essentiellement ex&eacute;cuter des commandes arbitraires sur votre syst&egrave;me avec
    les droits de l'utilisateur du serveur web, et peuvent par cons&eacute;quent &ecirc;tre
    extr&egrave;mement dangereux s'ils ne sont pas v&eacute;rifi&eacute;s avec soin.</p>

    <p>Tous les scripts CGI s'ex&eacute;cutent sous le m&ecirc;me utilisateur, il peuvent
    donc entrer en conflit (accidentellement ou d&eacute;lib&eacute;r&eacute;ment) avec d'autres
    scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il &eacute;crit donc
    un script qui efface la base de donn&eacute;es CGI de l'utilisateur B. Vous pouvez
    utiliser le programme <a href="../suexec.html">suEXEC</a> pour faire en
    sorte que les scripts s'ex&eacute;cutent sous des utilisateurs diff&eacute;rents. Ce
    programme est inclus dans la distribution d'Apache depuis la version 1.2
    et est appel&eacute; &agrave; partir de certaines portions de code du serveur Apache. Une
    autre m&eacute;thode plus connue est l'utilisation de
    <a href="http://cgiwrap.sourceforge.net/">CGIWrap</a>.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="nsaliasedcgi">CGI sans alias de script <a title="Lien permanent" href="#nsaliasedcgi" class="permalink">&para;</a></h2>

    

    <p>Vous ne devez permettre aux utilisateurs d'ex&eacute;cuter des scripts CGI
    depuis n'importe quel r&eacute;pertoire que dans l'&eacute;ventualit&eacute; o&ugrave; :</p>

    <ul>
      <li>Vous faites confiance &agrave; vos utilisateurs pour ne pas &eacute;crire de
      scripts qui vont d&eacute;lib&eacute;r&eacute;ment ou accidentellement exposer votre
      syst&egrave;me &agrave; une attaque.</li>
      <li>Vous estimez que le niveau de s&eacute;curit&eacute; dans les autres parties de
      votre site est si faible qu'un trou de s&eacute;curit&eacute; de plus ou de moins
      n'est pas tr&egrave;s important.</li>
      <li>Votre syst&egrave;me ne comporte aucun utilisateur, et personne ne visite
      jamais votre site.</li>
    </ul>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="saliasedcgi">CGI avec alias de script <a title="Lien permanent" href="#saliasedcgi" class="permalink">&para;</a></h2>

    

    <p>Le confinement des CGI dans des r&eacute;pertoires sp&eacute;cifiques permet &agrave;
    l'administrateur de contr&ocirc;ler ce que l'on met dans ces r&eacute;pertoires. Ceci
    est bien entendu mieux s&eacute;curis&eacute; que les CGI sans alias de script, mais
    seulement &agrave; condition que les utilisateurs avec les droits en &eacute;criture sur
    les r&eacute;pertoires soient dignes de confiance, et que l'administrateur ait la
    volont&eacute; de tester chaque programme ou script CGI &agrave; la recherche d'&eacute;ventuels
    trous de s&eacute;curit&eacute;.</p>

    <p>La plupart des sites choisissent cette approche au d&eacute;triment des CGI
    sans alias de script.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="dynamic">Autres sources de contenu dynamique <a title="Lien permanent" href="#dynamic" class="permalink">&para;</a></h2>

  

  <p>
  Les options de scripting int&eacute;gr&eacute;es qui s'ex&eacute;cutent en tant que partie du
  serveur lui-m&ecirc;me, comme <code>mod_php</code>, <code>mod_perl</code>,
  <code>mod_tcl</code>, et <code>mod_python</code>,
  s'ex&eacute;cutent sous le m&ecirc;me utilisateur que le serveur (voir la directive
  <code class="directive"><a href="../mod/mod_unixd.html#user">User</a></code>), et par cons&eacute;quent,
  les scripts que ces moteurs ex&eacute;cutent peuvent acc&eacute;der aux m&ecirc;mes ressources
  que le serveur. Certains moteurs de scripting peuvent proposer des
  restrictions, mais pour plus de s&ucirc;ret&eacute;, il vaut mieux partir du principe
  que ce n'est pas le cas.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="dynamicsec">S&eacute;curit&eacute; des contenus dynamiques <a title="Lien permanent" href="#dynamicsec" class="permalink">&para;</a></h2>

  

  <p>Quand vous utilisez des cadriciels &agrave; contenu dynamique &mdash;&nbsp;que ce soit &agrave;
  travers <code>mod_php</code>, <code>mod_perl</code>, <code>mod_python</code>
  ou tout autre g&eacute;n&eacute;rateur de contenu int&eacute;gr&eacute; ou externe &mdash;&nbsp;les responsabilit&eacute;s
  en mati&egrave;re de s&eacute;curit&eacute; s&rsquo;&eacute;tendent au-del&agrave; de httpd lui-m&ecirc;me. Chaque cadriciel
  poss&egrave;de ses propres mod&egrave;le de s&eacute;curit&eacute;, options de configuration et guides de
  durcissement. Consultez la documentation de la technologie que vous utilisez
  pour g&eacute;n&eacute;rer du contenu dynamique et maintenez cette derni&egrave;re &agrave; jour.</p>

  <p>Les principes g&eacute;n&eacute;raux s&rsquo;appliquent &agrave; tout cadriciel&nbsp;:</p>
  <ul>
  <li>Accordez des privil&egrave;ges minimaux &agrave; vos scripts et applications.</li>
  <li>V&eacute;rifiez et nettoyez toute entr&eacute;e de l&rsquo;utilisateur.</li>
  <li>Maintenez &agrave; jour votre cadriciel de contenu et ses d&eacute;pendances.</li>
  <li>V&eacute;rifiez la configuration de la s&eacute;curit&eacute; de votre cadriciel &mdash;&nbsp;les valeurs
  par d&eacute;faut ne sont pas toujours appropri&eacute;es en mati&egrave;re de s&eacute;curit&eacute;.</li>
  </ul>

  <p>Au niveau de httpd, un pare-feu d&rsquo;application web tel que <a href="https://modsecurity.org/">ModSecurity</a> peut fournir une couche
  suppl&eacute;mentaire de d&eacute;fense en inspectant et filtrant le trafic HTTP avant qu&rsquo;il
  n&rsquo;atteigne votre application.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="systemsettings">Protection de la configuration du syst&egrave;me <a title="Lien permanent" href="#systemsettings" class="permalink">&para;</a></h2>

    

    <p>Pour contr&ocirc;ler &eacute;troitement votre serveur, vous pouvez interdire
    l'utilisation des fichiers <code>.htaccess</code> qui permettent de
    passer outre les fonctionnalit&eacute;s de s&eacute;curit&eacute; que vous avez configur&eacute;es.
    Voici un moyen pour y parvenir :</p>

    <p>Ajoutez dans le fichier de configuration du serveur</p>

    <pre class="prettyprint lang-config">&lt;Directory "/"&gt;
    AllowOverride None
&lt;/Directory&gt;</pre>


    <p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans
    tous les r&eacute;pertoires, sauf ceux pour lesquels c'est explicitement
    autoris&eacute;.</p>

    <p>Notez que c'est la configuration par d&eacute;faut depuis Apache 2.3.9.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="protectserverfiles">Protection par d&eacute;faut des fichiers du serveur <a title="Lien permanent" href="#protectserverfiles" class="permalink">&para;</a></h2>

    

    <p>Le concept d'acc&egrave;s par d&eacute;faut est un aspect d'Apache qui est parfois mal
    compris. C'est &agrave; dire que, &agrave; moins que vous ne changiez explicitement ce
    comportement, si le serveur trouve son chemin vers un fichier en suivant
    les r&egrave;gles normales de correspondance URL - fichier, il peut le retourner
    aux clients.</p>

    <p>Consid&eacute;rons l'exemple suivant :</p>

    <div class="example"><p><code>
      # cd /; ln -s / public_html <br>
      puis acc&egrave;s &agrave; <code>http://localhost/~root/</code>
    </code></p></div>

    <p>Ceci permettrait aux clients de parcourir l'ensemble du syst&egrave;me de
    fichiers. Pour l'&eacute;viter, ajoutez le bloc suivant &agrave; la configuration
    de votre serveur :</p>

    <pre class="prettyprint lang-config">&lt;Directory "/"&gt;
    Require all denied
&lt;/Directory&gt;</pre>


    <p>ceci va interdire l'acc&egrave;s par d&eacute;faut &agrave; tous les fichiers du syst&egrave;me de
    fichiers. Vous devrez ensuite ajouter les blocs
    <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> appropri&eacute;s correspondant
    aux r&eacute;pertoires auxquels vous voulez autorisez l'acc&egrave;s. Par exemple,</p>

    <pre class="prettyprint lang-config">&lt;Directory "/usr/users/*/public_html"&gt;
    Require all granted
&lt;/Directory&gt;
&lt;Directory "/usr/local/httpd"&gt;
    Require all granted
&lt;/Directory&gt;</pre>


    <p>Portez une attention particuli&egrave;re aux interactions entre les directives
    <code class="directive"><a href="../mod/core.html#location">Location</a></code> et
    <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> ; par exemple, si une
    directive <code>&lt;Directory "/"&gt;</code> interdit un acc&egrave;s, une
    directive <code>&lt;Location "/"&gt;</code> pourra passer outre.</p>

    <p>De m&ecirc;me, soyez m&eacute;fiant en jouant avec la directive
    <code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> ; la positionner &agrave;
    <code>"./"</code> aurait le m&ecirc;me effet, pour root, que le premier exemple plus haut.
    Nous vous conseillons
    fortement d'inclure la ligne suivante dans le fichier de configuration de
    votre serveur :</p>

    <pre class="prettyprint lang-config">UserDir disabled root</pre>


  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="watchyourlogs">Surveillez vos journaux <a title="Lien permanent" href="#watchyourlogs" class="permalink">&para;</a></h2>

    

    <p>Pour vous tenir inform&eacute; de ce qui se passe r&eacute;ellement dans votre serveur,
    consultez r&eacute;guli&egrave;rement vos <a href="../logs.html">fichiers journaux</a>.
    Les fichiers journaux ne consignent que des &eacute;v&egrave;nements qui se sont d&eacute;j&agrave;
    produits, mais ils vous informeront sur la nature des attaques qui sont
    lanc&eacute;es et vous permettront de v&eacute;rifier si la configuration de votre
    s&eacute;curit&eacute; est efficace.</p>

    <p>Quelques exemples :</p>

    <pre class="prettyprint lang-sh">grep -c "\.\.\/" access_log
grep "client denied" error_log | tail -n 10</pre>


    <p>Le premier exemple compte les requ&ecirc;tes qui contiennent des s&eacute;quences de
    travers&eacute;e de chemin &mdash;&nbsp;un signe connu de recherche de vuln&eacute;rabilit&eacute;s. Le
    second liste les dix &laquo;&nbsp;client denied&nbsp;&raquo; les plus r&eacute;cents&nbsp;; par exemple&nbsp;:</p>
    <div class="example"><p><code>
      [Mon Apr 14 09:42:03.817295 2026] [authz_core:error] [pid 1234:tid 5678]
      [client 192.168.1.100:54312] AH01630: client denied by server configuration:
      /usr/local/apache2/htdocs/.env
    </code></p></div>

    <p>Comme vous pouvez le voir, les fichiers journaux ne mentionnent que ce
    qu&rsquo;il s&rsquo;est d&eacute;j&agrave; produit. Si le client avait pu acc&eacute;der au fichier
    <code>.env</code>, vous auriez vu une r&eacute;ponse <code>200</code> dans votre
    fichier <a href="../logs.html#accesslog">Access Log</a> &mdash; ce qui aurait
    signifi&eacute; que la configuration de votre serveur devait &ecirc;tre plus restrictive.
    Assurez-vous d&rsquo;interdire l&rsquo;acc&egrave;s aux fichiers sensibles&nbsp;:</p>

    <pre class="prettyprint lang-config">&lt;FilesMatch "^\.(?!well-known)"&gt;
    Require all denied
&lt;/FilesMatch&gt;</pre>


  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="merging">Fusion des sections de configuration <a title="Lien permanent" href="#merging" class="permalink">&para;</a></h2>

    

    <p>La fusion des sections de configuration est complexe et d&eacute;pend
    souvent des directives utilis&eacute;es. Vous devez syst&eacute;matiquement tester
    vos modifications pour v&eacute;rifier la mani&egrave;re dont les directives sont
    fusionn&eacute;es.</p>

    <p>Concernant les modules qui n'impl&eacute;mentent aucune logique de
    fusion, comme <code class="module"><a href="../mod/mod_access_compat.html">mod_access_compat</a></code>, le
    comportement des sections suivantes est tributaire de la pr&eacute;sence
    dans ces derni&egrave;res de directives appartenant &agrave; ces modules. La
    configuration est h&eacute;rit&eacute;e jusqu'&agrave; ce qu'une modification soit
    effectu&eacute;e ; &agrave; ce moment, la configuration est <em>remplac&eacute;e</em> et
    non fusionn&eacute;e.</p>
  </div></div>
<div class="bottomlang">
<p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
<a href="../fr/misc/security_tips.html" title="Fran&ccedil;ais">&nbsp;fr&nbsp;</a> |
<a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
<a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="T&uuml;rk&ccedil;e">&nbsp;tr&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2026 The Apache Software Foundation.<br>Autoris&eacute; sous <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="https://cwiki.apache.org/confluence/display/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a> | <a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2">Signaler un bug</a></p></div><script><!--//--><![CDATA[//><!--
if (typeof(prettyPrint) !== 'undefined') {
    prettyPrint();
}
var langToggle = document.querySelector('.lang-toggle');
var topLang = document.querySelector('.toplang');
if (langToggle && topLang) {
    langToggle.addEventListener('click', function() { topLang.classList.toggle('open'); });
}
var qv = document.getElementById('quickview');
if (qv) {
    document.body.appendChild(qv);
    var qvBtn = document.createElement('button');
    qvBtn.className = 'qv-toggle';
    qvBtn.setAttribute('aria-label', 'Toggle page navigation');
    qvBtn.innerHTML = '&#9776;';
    document.body.appendChild(qvBtn);
    qvBtn.addEventListener('click', function() {
        var isOpen = qv.classList.toggle('open');
        if (isOpen) {
            qv.style.top = window.scrollY + 10 + 'px';
        }
    });
    window.addEventListener('scroll', function() { qv.classList.remove('open'); });
}
//--><!]]></script>
</body></html>