Form and Input Security

Web Security Issues

XSS – Cross-Site Scripting

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. The media has helped make cross-site scripting (XSS) a familiar term, and the attention is deserved. It is one of the most common security vulnerabilities in web applications, and many popular open source PHP applications suffer from constant XSS vulnerabilities.

Example XSS attacks

Passing javascript as an input parameter<script>// <![CDATA[alert('1'); // ]]></script>

XSRF/CSRF – Cross-Site Request Forgeries

The CSRF attack is quite different to XSS attacks. In CSRF attack, the end user can perform unwanted actions on the authenticated websites and can transfer malicious commands to the site to execute any undesirable action. CSRF can’t read the request data and mostly targets the state changing request by sending any link or altered data in HTML tags. It can force the user to perform state changing requests like transferring funds, changing their email addresses etc.

Session Hijacking

Session hijacking is a particular type of malicious web attack in which the attacker secretly steals the session ID of the user. That session ID is sent to the server where the associated $_SESSION array validates its storage in the stack and grants access to the application. Session hijacking is possible through an XSS attack or when someone gains access to the folder on a server where the session data is stored.

File uploading

Security Measures

Keep systems, languages and apps up-to-date


All form data should be _POST_ed to the server.

Define post as the method param in the form tag.

<form method="post" action="">

Server-side, check for and extract parameters only from POST.

    $name  = $_POST["name"];
    $email = $_POST["email"];

Use whitelisted params

Validate URLS

if(!filter_var($_POST['URL-main'],FILTER_VALIDATE_URL)) {
   die('Please insert a valid URL');

Use token matching

Filter variables used to build the form:

<form method="post" action="<?php echo htmlspecialchars($my_action_url);?>">

Cleaning data

Remember this saying: “Sanitize input early, sanitize output late”

At input: Validate and Sanitize

As data arrives your first step should be to validate it. Make sure integers are in fact integers and that no unusual or disallowed data is arriving in your application. The next step at input is to sanitize it and strip out anything potentially harmful. You will rarely escape data at input because your application will most likely need to work with the raw data, and you have already made it safe by validating and sanitizing.

At output: Sanitize and Escape

As data leaves your application, you need to remove any potentially harmful data again through sanitization. The reason you sanitize again on output is because a hacker may have tricked your application into creating harmful data for output, so you need to re-check that your output data is safe.

Then you need to escape the data to make sure it is suitable for whatever medium it is being output to. You may need to turn HTML tags into HTML entities to make them safe for the web browser. Or you may need to remove single and double quotes if your output is going to be used as an HTML attribute.

Functions like intval() that strip out everything except integers are useful for sanitization.


Validation routines are normally used in a conditional statement e.g.

if(filter_var($address, FILTER_VALIDATE_EMAIL)){ 
    echo "Email is valid."; 
} else { 
    echo "Not valid."; 


Sanitization takes some data and cleans it for you, returning the clean version. e.g.

//Remove all characters from the email except letters, digits and !#$%&'*+-=?^_`{|}~@.[] 
echo filter_var($dirtyAddress, FILTER_SANITIZE_EMAIL);


Escaping routines make potentially harmful data safe. They are frequently used as follows:

Thanks for your order. Please visit us again.
You ordered <?php echo esc_html($productName); ?>