Sending and retrieving form data

  • Revision slug: HTML/Forms/Sending_and_retrieving_form_data
  • Revision title: Sending and retrieving form data
  • Revision id: 341335
  • Created:
  • Creator: Sheppy
  • Is current revision? No
  • Comment

Revision Content

In many cases, the purpose of an HTML Form is to send data to a server. The server will process the data and then send a response to the user. This seems simple, but it's important to keep a few things in mind to ensure that the data will not damage your server or cause trouble for your users.

Where does the data go?

About client/server architecture

The web is based on a very basic client/server architecture that can be summarized as follows: a client (usually a Web browser) sends a request to a server (most of the time a web server like Apache, Nginx, IIS, Tomcat, etc.), using the HTTP protocol. The server answers the request using the same protocol.

A basic schema of the Web client/server architecture

On the client side, an HTML form is nothing more than a convenient user-friendly way to configure an HTTP request to send data to a server. It makes it possible for the user to provide information to be delivered in the HTTP request.

On the client side: defining how to send the data

To define the manner in which the data will be sent, you use the {{HTMLElement("form")}} element. All of its attributes are designed to let you configure the request to be sent when a user hits a submit button. The two most important attributes are {{htmlattrxref("action","form")}} and {{htmlattrxref("method","form")}}.

The {{htmlattrxref("action","form")}} attribute

This attribute defines where the data gets sent. Its value must be a valid URL. If this attribute isn't provided, the data will be sent to the URL of the page containing the form.

Examples

In this first example, the data is sent to http://foo.com.

<form action="http://foo.com">

Here, the data is sent to the same server that hosts the form's page, but to a different URL on the server:

<form action="/somewhere_else">

When specified with no attributes, as below, the {{HTMLElement("form")}} attribute causes the data to be sent to the page that includes the form:

<form>

Many older pages use the following notation to indicate that the data should be sent to the same page that contains the form; this was required because until HTML5, the {{htmlattrxref("form", "action")}} attribute was required. This isn't needed any longer.

<form action="#">

Note: It's possible to specify a URL that uses the HTTPS (secure HTTP) protocol. When you do this, the data is encrypted along with the rest of the request, even if the form itself is hosted on an insecure page accessed using HTTP. On the other hand, if the form is hosted on secure page but you specify an insecure HTTP URL with the {{htmlattrxref("action","form")}} attribute, all browsers display a security warning to the user each time they try to send data, because the data will not be encrypted.

The {{htmlattrxref("method","form")}} attribute

This attribute defines how data is sent. The HTTP protocol provides several ways to perform a request; HTML forms data can be sent through at least two of them: the GET method and the POST method.

To understand the difference between those two methods, let's step back and examine how HTTP works. Each time you want to reach a resource on the Web, the browser sends a request to a URL. An HTTP request consists of two parts: a header that contains a bunch of global metadata about the browser's capabilities, and a body that can contain information necessary to the server to process the specific request.

The GET method

The GET method is the method used by the browser to ask the server to send back a given resource: "Hey server, I want to get this resource." In this case, the browser sends an empty body. Because the body is empty, if a form is sent using this method, the data sent to the server is appended to the URL.

Example

Consider the following form:

<form action="http://foo.com" method="get">
  <input name="say" value="Hi">
  <input name="to" value="Mom">
  <button>Send my greetings</button>
</form>

With the GET method, the HTTP request looks like this:

GET /?say=Hi&to=Mom HTTP/1.1
Host: foo.com
The POST method

The POST method is a little different. It's the method the browser sends the server to ask for a response that takes into account the data provided in the body of the HTTP request: "Hey server, take a look at this data and send me back an appropriate result." If a form is sent using this method, the data is appended to the body of the HTTP request.

Example

Consider this form (the same one as above):

<form action="http://foo.com" method="post">
  <input name="say" value="Hi">
  <input name="to" value="Mom">
  <button>Send my greetings</button>
</form>

When sent using the POST method, the HTTP request looks like this:

POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

say=Hi&to=Mom

The Content-Length header indicates the size of the body, and the Content-Type header indicates the kind of ressource sent to the server. We'll discuss these headers in a bit.

Of course, HTTP requests are never displayed to the user (if you want to see them, you have to use tools such as the Firefox Web Console or the Chrome Developer Tools). The only thing displayed to the user is the URL called. So with a GET request, the user will see the data in their URL bar, but with a POST request, they won't. This can be very important for two reasons:

  1. If you have to send a password (or any sensitive piece of data), never use the GET method or you risk displaying it in the URL bar.
  2. If you have to send a large amount of data, the POST method is preferred because some browsers limit the sizes of URLs. In addition, many servers limit the length of URLs they accept.

On the server side: retrieving the data

Whichever HTTP method you choose, the server receives a string that will be parsed in order to get the data as a list of key/value pairs. The way you access this list depends on the development platform you use and on any specific frameworks you may be using with it. The technology you use also determines how duplicate keys are handled; often, the most last-received value for a given key is given priority.

Example: Raw PHP

PHP offers some global objects to access the data. Assuming you've used the POST method, the following example just takes the data and displays it to the user. Of course, what you do with the data is up to you. You might display it, store it into a database, send them by email, or process it in some other way.

<?php
  // The global $_POST variable allow to access the data send with the POST method
  // To access the data send with the GET method, you can use $_GET
  $say = htmlspecialchars($_POST['say']);
  $to  = htmlspecialchars($_POST['to']);

  echo  $say, ' ', $to;

This example displays a page with the data we sent. In our example from before, the output would be:

Hi Mom

Example: Raw Python

This example uses Python to do the same thing--display the provided data on a web page. It uses the CGI Python package to access the form data.

#!/usr/bin/env python
import html
import cgi
import cgitb; cgitb.enable()     # for troubleshooting

print("Content-Type: text/html") # HTTP header to say HTML is following
print()                          # blank line, end of headers

form = cgi.FieldStorage()
say  = html.escape(form["say"].value);
to   = html.escape(form["to"].value);

print(say, " ", to)

The result is the same as with PHP:

Hi Mom

Other languages and frameworks

There are many other server-side technologies you can use for form handling, including Perl, Java, .Net, Ruby, etc. Just pick the one you like best. That said, it's worth noting that it's very uncommon to directly use these technologies, because it can be tricky. It's more common to use one of the many nice frameworks that make handling forms easier, such as:

It's worth noting that even using these frameworks, working with forms isn't necessarily easy. But it's much better, and will save you a lot of time.

A special case: sending files

Files are a special case with HTML forms. They are binary data—or considered as such—where all others data are text data. Because HTTP is a text protocol, there are special requirements to handle binary data.

The {{htmlattrxref("enctype","form")}} attribute

This attribute lets you specify the value of the Content-Type HTTP header. This header is very important because it tells the server what kind of data is being sent. By default, its value is application/x-www-form-urlencoded. In human terms, this means: "This is form data that has been encoded into URL form."

But if you want to send files, you have to do two things:

  • Set the {{htmlattrxref("method","form")}} attribute to POST because file content can't be put inside a URL parameter using a form.
  • Set the value of {{htmlattrxref("enctype","form")}} to multipart/form-data because the data will be split into multiple parts, one for each file plus one for the text of the form body that may be sent with them.

For example:

<form method="post" enctype="multipart/form-data>
  <input type="file" name="myFile">
  <button>Send the file</button>
</form>

Note: Some browsers support the {{htmlattrxref("multiple","input")}} attribute on the {{HTMLElement("input")}} element in order to send more than one file with only one input element. The way those files are handled server side really depends on the technology used on the server. As mentioned previously, using a framework will make your life a lot easier.

Warning: Many servers are configured with a size limit for files and HTTP requests in order to prevent abuse. It's important to check what this limit is before sending a file. HOW DO YOU CHECK THIS?

Security concerns

Each time you send data to a server you have to take care about security. HTML Forms are one of the first attack vectors against servers. The problems never come from the HTML forms themselves; it comes from the way data are handled server side.

Common security flows

Depending on what you're doing, there are some very well known security issues:

XSS and CSRF

Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) are common type of attacks when you display data send by a user to the user himself or to another user.

XSS allows attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Their effect may range from a petty nuisance to a significant security risk.

CSRF are really closed from XSS attack in the way they start the same way—By injecting client-side script into Web pages—but their target is different. CSRF attacker try to escalate privilege to force a granted user (such as a site administrator) to perform an action it shouldn't (for example, sending data to an untrusted user).

XSS attack exploit the trust a user have for a web site when CSRF attack exploit the trust a web site have for a user.

To prevent this you should always check what a user send to your server and if you have to display that content, try to not display HTML content provide by the user. Almost all frameworks on the market today implement a minimal filter that removes the HTML {{HTMLElement("script")}}, {{HTMLElement("iframe")}} and {{HTMLElement("object")}} elements from data send by any user.

SQL Injection

SQL Injection is a type of attack that tries to perform action on a database used by the target web site. Basically it sends an SQL request and expects the server to execute it (many time when the application server try to store the data). This is actually one of the main vector attacks against web sites.

The consequence can be terrible from data loss to access to a whole infrastructure by using privilege escalation. This is a very serious threat and you should never store data send by a user without performing some sanitization (for example by using mysql_real_escape_string on a PHP/MySQL infrastructure).

HTTP Header Injection and e-mail injection

This kind of attacks can occur when your application build HTTP Headers or e-mails based on the user inputs. They will not directly damage your system or affect your users but it's an open door to deeper problems such as Session hijacking or Phishing attack.

Those attack are mainly silent and can turn your server into a zombie.

Be paranoid: Never trust your users

So, how to fight those threats? Well, this is a topic far beyond this guide, however there are a few rules it's good to have in mind. The most important rule is: Never ever trust your users, including yourself (I'm dead serious); even a trusted user could have been hijack.

Each data that come to your server must be check and sanitize. Always. No exception.

  • Escape dangerous characters (it depends on the context the data are used, but all server side languages have functions to do that)
  • Limit the incoming amount of data to what is necessary only
  • Sandbox uploaded files (store them on a different server and allow access to the file only through a different subdomain or even better through a fully different domain name)

If you follow those 3 rules of thumb, you should avoid a large part of the troubles, but it never worth a good security review performed by third party people. As I said, don't even trust yourself ;)

Conclusion

As you can see, sending form data is easy, but securing an application can be tricky. Just remember that a front-end developer is not the one who should define the security model of the data. Yes, as we'll see, it's possible to perform client side data validation but the server can't trust this validation because it has no way to truly know what really happens on the client side.

See also

If you want to learn more about securing a web application, you can dig into those few resources:

Revision Source

<p>In many cases, the purpose of an <a href="/en-US/docs/HTML/Forms" title="/en-US/docs/HTML/Forms">HTML Form</a> is to send data to a server. The server will process the data and then send a response to the user. This seems simple, but it's important to keep a few things in mind to ensure that the data will not damage your server or cause trouble for your users.</p>
<h2 id="Where_data_go.">Where does the data go?</h2>
<h3 id="A_quick_reminder_about_the_Client.2FServer_architecture">About client/server architecture</h3>
<p>The web is based on a very basic client/server architecture that can be summarized as follows: a client (usually a Web browser) sends a request to a server (most of the time a web server like <a href="http://httpd.apache.org/" rel="external" title="http://www.apache.org/">Apache</a>, <a href="http://nginx.com/" rel="external" title="http://nginx.com/">Nginx</a>, <a href="http://www.iis.net/" rel="external" title="http://www.iis.net/">IIS</a>, <a href="http://tomcat.apache.org/" rel="external" title="http://tomcat.apache.org/">Tomcat</a>, etc.), using the <a href="/en-US/docs/HTTP" title="/en-US/docs/HTTP">HTTP protocol</a>. The server answers the request using the same protocol.</p>
<p><img alt="A basic schema of the Web client/server architecture" src="/files/4291/client-server.png" style="width: 400px; height: 141px;" /></p>
<p>On the client side, an HTML form is nothing more than a convenient user-friendly way to configure an HTTP request to send data to a server. It makes it possible for the user to provide information to be delivered in the HTTP request.</p>
<h3 id="On_the_client_side.3A_define_how_to_send_data">On the client side: defining how to send the data</h3>
<p>To define the manner in which the data will be sent, you use the {{HTMLElement("form")}} element. All of its attributes are designed to let you configure the request to be sent when a user hits a submit button. The two most important attributes are {{htmlattrxref("action","form")}} and {{htmlattrxref("method","form")}}.</p>
<h4 id="The_.7B.7Bhtmlattrxref(.22action.22.2C.22form.22).7D.7D_attribute">The {{htmlattrxref("action","form")}} attribute</h4>
<p>This attribute defines where the data gets sent. Its value must be a valid URL. If this attribute isn't provided, the data will be sent to the URL of the page containing the form.</p>
<h5>Examples</h5>
<p>In this first example, the data is sent to http://foo.com.</p>
<pre class="brush: html">
&lt;form action="http://foo.com"&gt;</pre>
<p class="brush: html">Here, the data is sent to the same server that hosts the form's page, but to a different URL on the server:</p>
<pre class="brush: html">
&lt;form action="/somewhere_else"&gt;</pre>
<p class="brush: html">When specified with no attributes, as below, the {{HTMLElement("form")}} attribute causes the data to be sent to the page that includes the form:</p>
<pre class="brush: html">
&lt;form&gt;</pre>
<p class="brush: html">Many older pages use the following notation to indicate that the data should be sent to the same page that contains the form; this was required because until HTML5, the {{htmlattrxref("form", "action")}} attribute was required. This isn't needed any longer.</p>
<pre class="brush: html">
&lt;form action="#"&gt;</pre>
<div class="note">
  <p><strong>Note:</strong> It's possible to specify a URL that uses the HTTPS (secure HTTP) protocol. When you do this, the data is encrypted along with the rest of the request, even if the form itself is hosted on an insecure page accessed using HTTP. On the other hand, if the form is hosted on secure page but you specify an insecure HTTP URL with the {{htmlattrxref("action","form")}} attribute, all browsers display a security warning to the user each time they try to send data, because the data will not be encrypted.</p>
</div>
<h4 id="The_.7B.7Bhtmlattrxref(.22method.22.2C.22form.22).7D.7D_attribute">The {{htmlattrxref("method","form")}} attribute</h4>
<p>This attribute defines how data is sent. The <a href="/en-US/docs/HTTP" title="/en-US/docs/HTTP">HTTP protocol</a> provides several ways to perform a request; HTML forms data can be sent through at least two of them: the <code>GET</code> method and the <code>POST</code> method.</p>
<p>To understand the difference between those two methods, let's step back and examine how HTTP works. Each time you want to reach a resource on the Web, the browser sends a request to a URL. An HTTP request consists of two parts: a header that contains a bunch of global metadata about the browser's capabilities, and a body that can contain information necessary to the server to process the specific request.</p>
<h5>The GET method</h5>
<p>The <code>GET</code> method is the method used by the browser to ask the server to send back a given resource: "Hey server, I want to get this resource." In this case, the browser sends an empty body. Because the body is empty, if a form is sent using this method, the data sent to the server is appended to the URL.</p>
<h6>Example</h6>
<p>Consider the following form:</p>
<pre class="brush: html">
&lt;form action="http://foo.com" method="get"&gt;
  &lt;input name="say" value="Hi"&gt;
  &lt;input name="to" value="Mom"&gt;
  &lt;button&gt;Send my greetings&lt;/button&gt;
&lt;/form&gt;</pre>
<p>With the <code>GET</code> method, the HTTP request looks like this:</p>
<pre>
GET /?say=Hi&amp;to=Mom HTTP/1.1
Host: foo.com</pre>
<h5>The POST method</h5>
<p>The <code>POST</code> method is a little different. It's the method the browser sends the server to ask for a response that takes into account the data provided in the body of the HTTP request: "Hey server, take a look at this data and send me back an appropriate result." If a form is sent using this method, the data is appended to the body of the HTTP request.</p>
<h6>Example</h6>
<p>Consider this form (the same one as above):</p>
<pre class="brush: html">
&lt;form action="http://foo.com" method="post"&gt;
  &lt;input name="say" value="Hi"&gt;
  &lt;input name="to" value="Mom"&gt;
  &lt;button&gt;Send my greetings&lt;/button&gt;
&lt;/form&gt;</pre>
<p>When sent using the <code>POST</code> method, the HTTP request looks like this:</p>
<pre>
POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

say=Hi&amp;to=Mom</pre>
<p>The <code>Content-Length</code> header indicates the size of the body, and the <code>Content-Type</code> header indicates the kind of ressource sent to the server. We'll discuss these headers in a bit.</p>
<p>Of course, HTTP requests are never displayed to the user (if you want to see them, you have to use tools such as the Firefox <a href="/en-US/docs/Tools/Web_Console" title="/en-US/docs/Tools/Web_Console">Web Console</a> or the <a href="https://developers.google.com/chrome-developer-tools/" title="https://developers.google.com/chrome-developer-tools/">Chrome Developer Tools</a>). The only thing displayed to the user is the URL called. So with a <code>GET</code> request, the user will see the data in their URL bar, but with a <code>POST</code> request, they won't. This can be very important for two reasons:</p>
<ol>
  <li>If you have to send a password (or any sensitive piece of data), never use the <code>GET</code> method or you risk displaying it in the URL bar.</li>
  <li>If you have to send a large amount of data, the <code>POST</code> method is preferred because some browsers limit the sizes of URLs. In addition, many servers limit the length of URLs they accept.</li>
</ol>
<h3 id="On_the_server_side.3A_How_to_retrieve_the_data.">On the server side: retrieving the data</h3>
<p>Whichever HTTP method you choose, the server receives a string that will be parsed in order to get the data as a list of key/value pairs. The way you access this list depends on the development platform you use and on any specific frameworks you may be using with it. The technology you use also determines how duplicate keys are handled; often, the most last-received value for a given key is given priority.</p>
<h4 id="Raw_PHP_example">Example: Raw PHP</h4>
<p>PHP offers some global objects to access the data. Assuming you've used the <code>POST</code> method, the following example just takes the data and displays it to the user. Of course, what you do with the data is up to you. You might display it, store it into a database, send them by email, or process it in some other way.</p>
<pre class="brush: php">
&lt;?php
  // The global $_POST variable allow to access the data send with the POST method
  // To access the data send with the GET method, you can use $_GET
  $say = htmlspecialchars($_POST['say']);
  $to  = htmlspecialchars($_POST['to']);

  echo  $say, ' ', $to;</pre>
<p>This example displays a page with the data we sent. In our example from before, the output would be:</p>
<pre>
Hi Mom</pre>
<h4 id="Raw_Python_example">Example: Raw Python</h4>
<p>This example uses Python to do the same thing--display the provided data on a web page. It uses the <a href="http://docs.python.org/3/library/cgi.html" rel="external" title="http://docs.python.org/3/library/cgi.html">CGI Python package</a> to access the form data.</p>
<pre class="brush: python">
#!/usr/bin/env python
import html
import cgi
import cgitb; cgitb.enable()     # for troubleshooting

print("Content-Type: text/html") # HTTP header to say HTML is following
print()                          # blank line, end of headers

form = cgi.FieldStorage()
say  = html.escape(form["say"].value);
to   = html.escape(form["to"].value);

print(say, " ", to)</pre>
<p>The result is the same as with PHP:</p>
<pre>
Hi Mom</pre>
<h4 id="Other_languages_and_frameworks">Other languages and frameworks</h4>
<p>There are many other server-side technologies you can use for form handling, including <a href="/en-US/docs/" title="/en-US/docs/">Perl</a>, <a href="/en-US/docs/" title="/en-US/docs/">Java</a>, <a href="http://www.microsoft.com/net" title="http://www.microsoft.com/net">.Net</a>, <a href="/en-US/docs/" title="/en-US/docs/">Ruby</a>, etc. Just pick the one you like best. That said, it's worth noting that it's very uncommon to directly use these technologies, because it can be tricky. It's more common to use one of the many nice frameworks that make handling forms easier, such as:</p>
<ul>
  <li><a href="http://symfony.com/" rel="external" title="http://symfony.com/">Symfony</a> for PHP</li>
  <li><a href="https://www.djangoproject.com/" rel="external" title="https://www.djangoproject.com/">Django</a> for Python</li>
  <li><a href="http://rubyonrails.org/" rel="external" title="http://rubyonrails.org/">Ruby On Rails</a> for Ruby</li>
  <li><a href="http://grails.org/" rel="external" title="http://grails.org/">Grails</a> for Java</li>
  <li>etc.</li>
</ul>
<p>It's worth noting that even using these frameworks, working with forms isn't necessarily <em>easy</em>. But it's much better, and will save you a lot of time.</p>
<h2 id="A_special_case.3A_sending_files">A special case: sending files</h2>
<p>Files are a special case with HTML forms. They are binary data—or considered as such—where all others data are text data. Because HTTP is a text protocol, there are special requirements to handle binary data.</p>
<h3 id="The_.7B.7Bhtmlattrxref(.22enctype.22.2C.22form.22).7D.7D_attribute">The {{htmlattrxref("enctype","form")}} attribute</h3>
<p>This attribute lets you specify the value of the <code>Content-Type</code> HTTP header. This header is very important because it tells the server what kind of data is being sent. By default, its value is <code>application/x-www-form-urlencoded</code>. In human terms, this means: "This is form data that has been encoded into URL form."</p>
<p>But if you want to send files, you have to do two things:</p>
<ul>
  <li>Set the {{htmlattrxref("method","form")}} attribute to <code>POST</code> because file content can't be put inside a URL parameter using a form.</li>
  <li>Set the value of {{htmlattrxref("enctype","form")}} to <code>multipart/form-data</code> because the data will be split into multiple parts, one for each file plus one for the text of the form body that may be sent with them.</li>
</ul>
<p>For example:</p>
<pre class="brush: html">
&lt;form method="post" enctype="multipart/form-data&gt;
  &lt;input type="file" name="myFile"&gt;
  &lt;button&gt;Send the file&lt;/button&gt;
&lt;/form&gt;</pre>
<div class="note">
  <p><strong>Note:</strong> Some browsers support the {{htmlattrxref("multiple","input")}} attribute on the {{HTMLElement("input")}} element in order to send more than one file with only one input element. The way those files are handled server side really depends on the technology used on the server. As mentioned previously, using a framework will make your life a lot easier.</p>
</div>
<div class="warning">
  <p><strong>Warning:</strong> Many servers are configured with a size limit for files and HTTP requests in order to prevent abuse. It's important to check what this limit is before sending a file. <strong>HOW DO YOU CHECK THIS?</strong></p>
</div>
<h2 id="Security_concerns">Security concerns</h2>
<p>Each time you send data to a server you have to take care about security. HTML Forms are one of the first attack vectors against servers. The problems never come from the HTML forms themselves; it comes from the way data are handled server side.</p>
<h3 id="Common_security_flows">Common security flows</h3>
<p>Depending on what you're doing, there are some very well known security issues:</p>
<h4 id="XSS_and_CSRF">XSS and CSRF</h4>
<p>Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) are common type of attacks when you display data send by a user to the user himself or to another user.</p>
<p>XSS allows attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same origin policy. Their effect may range from a petty nuisance to a significant security risk.</p>
<p>CSRF are really closed from XSS attack in the way they start the same way—By injecting client-side script into Web pages—but their target is different. CSRF attacker try to escalate privilege to force a granted user (such as a site administrator) to perform an action it shouldn't (for example, sending data to an untrusted user).</p>
<p>XSS attack exploit the trust a user have for a web site when CSRF attack exploit the trust a web site have for a user.</p>
<p>To prevent this you should always check what a user send to your server and if you have to display that content, try to not display HTML content provide by the user. Almost all frameworks on the market today implement a minimal filter that removes the HTML {{HTMLElement("script")}}, {{HTMLElement("iframe")}} and {{HTMLElement("object")}} elements from data send by any user.</p>
<h4 id="SQL_Injection">SQL Injection</h4>
<p>SQL Injection is a type of attack that tries to perform action on a database used by the target web site. Basically it sends an SQL request and expects the server to execute it (many time when the application server try to store the data). This is actually <a href="https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project" rel="external" title="https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project">one of the main vector attacks against web sites</a>.</p>
<p>The consequence can be terrible from data loss to access to a whole infrastructure by using privilege escalation. This is a very serious threat and you should never store data send by a user without performing some sanitization (for example by using <a href="http://www.php.net/manual/en/function.mysql-real-escape-string.php" rel="external" title="http://www.php.net/manual/en/function.mysql-real-escape-string.php">mysql_real_escape_string</a> on a PHP/MySQL infrastructure).</p>
<h4 id="HTTP_Header_Injection_and_e-mail_injection">HTTP Header Injection and e-mail injection</h4>
<p>This kind of attacks can occur when your application build HTTP Headers or e-mails based on the user inputs. They will not directly damage your system or affect your users but it's an open door to deeper problems such as Session hijacking or Phishing attack.</p>
<p>Those attack are mainly silent and can turn your server into a <a href="http://en.wikipedia.org/wiki/Zombie_(computer_science)" rel="exernal" title="http://en.wikipedia.org/wiki/Zombie_(computer_science)">zombie</a>.</p>
<h3 id="Be_paranoid.3A_Never_trust_your_users">Be paranoid: Never trust your users</h3>
<p>So, how to fight those threats? Well, this is a topic far beyond this guide, however there are a few rules it's good to have in mind. The most important rule is: Never ever trust your users, including yourself (I'm dead serious); even a trusted user could have been hijack.</p>
<p>Each data that come to your server must be check and sanitize. Always. No exception.</p>
<ul>
  <li>Escape dangerous characters (it depends on the context the data are used, but all server side languages have functions to do that)</li>
  <li>Limit the incoming amount of data to what is necessary only</li>
  <li>Sandbox uploaded files (store them on a different server and allow access to the file only through a different subdomain or even better through a fully different domain name)</li>
</ul>
<p>If you follow those 3 rules of thumb, you should avoid a large part of the troubles, but it never worth a good security review performed by third party people. As I said, don't even trust yourself ;)</p>
<h2 id="Conclusion">Conclusion</h2>
<p>As you can see, sending form data is easy, but securing an application can be tricky. Just remember that a front-end developer is not the one who should define the security model of the data. Yes, as we'll see, it's possible to <a href="/en-US/docs/HTML/Forms/Data_form_validation" title="/en-US/docs/HTML/Forms/Data_form_validation">perform client side data validation</a> but the server can't trust this validation because it has no way to truly know what really happens on the client side.</p>
<h2 id="See_also">See also</h2>
<p>If you want to learn more about securing a web application, you can dig into those few resources:</p>
<ul>
  <li><a href="https://www.owasp.org/index.php/Main_Page" rel="external" title="https://www.owasp.org/index.php/Main_Page">The Open Web Application Security Project (OWASP)</a></li>
  <li><a href="http://shiflett.org/" rel="external" title="http://shiflett.org/">Chris Shiflett's blog about PHP Security</a></li>
  <li><a href="https://code.google.com/intl/en/edu/security/index.html" rel="external" title="https://code.google.com/intl/en/edu/security/index.html">Learning material from Google</a></li>
</ul>
Revert to this revision