<li><img alt="" src="../images/down.gif" /> <a href="#socache">Performance and Cacheing</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#example">Configuration Example</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#exposed">Exposing Login Information</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#security">Preventing SQL injections</a></li>
</ul><h3>See also</h3>
<ul class="seealso">
<li><code class="directive"><a href="../mod/mod_authn_core.html#authname">AuthName</a></code></li>
<p>This has the potential to dramatically simplify the coding and
configuration required in some web applications.
</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="security" id="security">Preventing SQL injections</a></h2>
+
+ <p>It depends on what DBD driver and backend you use. With most
+ drivers you don't have to do anything : the statement is prepared
+ by the database at startup, and user input is used only as data.
+ But you may need to untaint your input. At the time of writing,
+ the only driver that requires you to take care is FreeTDS.</p>
+ <p>Please read <code class="module"><a href="../mod/mod_dbd.html">mod_dbd</a></code> documentation for more information
+ about security on this scope.</p>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="AuthDBDUserPWQuery" id="AuthDBDUserPWQuery">AuthDBDUserPWQuery</a> <a name="authdbduserpwquery" id="authdbduserpwquery">Directive</a></h2>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_authn_dbd</td></tr>
</table>
<p>The <code class="directive">AuthDBDUserRealmQuery</code> specifies an
- SQL query to look up a password for a specified user and realm in a
+ SQL query to look up a password for a specified user and realm in a
digest authentication process.
The user's ID and the realm, in that order, will be passed as string
parameters when the SQL query is executed. They may be referenced
</p>
</section>
+<section id="security">
+<title>Preventing SQL injections</title>
+ <p>It depends on what DBD driver and backend you use. With most
+ drivers you don't have to do anything : the statement is prepared
+ by the database at startup, and user input is used only as data.
+ But you may need to untaint your input. At the time of writing,
+ the only driver that requires you to take care is FreeTDS.</p>
+ <p>Please read <module>mod_dbd</module> documentation for more information
+ about security on this scope.</p>
+</section>
+
<directivesynopsis>
<name>AuthDBDUserPWQuery</name>
<description>SQL query to look up a password for a user</description>
<usage>
<p>The <directive>AuthDBDUserRealmQuery</directive> specifies an
- SQL query to look up a password for a specified user and realm in a
+ SQL query to look up a password for a specified user and realm in a
digest authentication process.
The user's ID and the realm, in that order, will be passed as string
parameters when the SQL query is executed. They may be referenced