Secure PHP Programming Practices

Secure PHP Programming PracticesIt is accepted that PHP has been one of the most useful and useful when it comes to web development. There are plenty of great features and functionalities that PHP has been packaged with. With the growth PHP has been through variety of threats and malicious activities. To overcome some of these and to avoid some of the mistakes it is highly advisable for any PHP Programmer to follow a highly secure yet simple programming techniques in order to overcome these issues.

This article would discuss about three of the major techniques using which a Professional PHP Developer can write a secure PHP Code.

PHP Programmers do know that certain aspects of the code are accessible and that can be avoided, but many of them either don’t follow the practice or they just don’t know.

Three major aspects are:

  • Global Variables
  • Cross Site Scripting (XSS)
  • SQL Code

Global Variables

Register Globals – A PHP feature is one of the most useful yet can be used to access the data of the website, which is not supposed to be accessed. For example, if you have not initialized the variable and if you are using that as part of the verification process for the administration, the value that is uninitialised can be treated as the actual value, and one can actually go through the data that is not supposed to be visible to anyone except administrator.

To overcome this issue, it is best to disable the Register Globals and use the local variables for the programs and initialize them. But as far as possible, use of Register Globals should be avoided to maximize the security of the website.

Cross Site Scripting (XSS)

Cross Site Scripting is highly used with AJAX. Specifically the use of comment box when the AJAX is called and the user is asked to login, the details once logged in are stored in the cookies and a malicious user accessing the server remotely can definitely get hold of that, compromising the security of the website database. Normally, when the JavaScript (JS) runs when the person writes the comments and the content can be captured and manipulated by the same malicious user which may affect the database.

It is a great practice for the PHP Programmers to make highest use of filters in order to protect the database from any inputs that are not filter qualified, and if detected, programmer can use die() function to exist the task and stop inputting that value to the database. Again, while outputting the same database the same practice needs to be followed. This would be a great practice to make sure that you website doesn’t store plenty of spammy or malicious entries of comments in the database.

Php Developer India

SQL Code

The SQL code is another place where the malicious users can enter as and when the dynamic code is written without completely filtering the data. This is just like one of those Cross Site Scripting feature. There is a very simple method that a PHP Developer should follow: First of all as far as possible the code should not be dynamic, and in conditions where it is necessary to write the dynamic code in that case, the code before inputting to the database should be verified using the filters if the values that are inserted are actually true or not. This can be done more effectively by typecasting the data.

It is true that there are plenty of other ways to break the security and get in but majorly, these are the areas, if taken care of properly there are lesser chances of website being compromised.

Ofcouse some of the other recommendations we prefer would be:

  • Securing the Files using protections.
  • Database needs to be Protected using a secure link and password.
  • Verified and validated inputs.
  • Systematic protection of the entire PHP Program or a system.

Once PHP is used with highly secure and most efficient way for coding, the application, or website or the program developed would definitely be protected from most of the spammy and malicious activities and malicious users. Follow the correct practices of PHP Programming and enjoy the luxury of plenty of great features from PHP to create biggest innovations in the industry.

We would love to know, if you can throw some coding examples of how each point can be used to break the security and an example of how to protect that. A great tutorial and practice for all of the PHP Programmers. Lets be part of secure PHP Coding practices.


One thought on “Secure PHP Programming Practices

  1. A cross-site scripting attack is one of the top 5 security attacks carried out on a daily basis across the Internet, and your PHP scripts may not be immune.

    Also known as XSS, the attack is basically a type of code injection attack which is made possible by incorrectly validating user data, which usually gets inserted into the page through a web form or using an altered hyperlink. The code injected can be any malicious client-side code, such as JavaScript, VBScript, HTML, CSS, Flash, and others. The code is used to save harmful data on the server or perform a malicious action within the user’s browser.

    Unfortunately, cross-site scripting attacks occurs mostly, because developers are failing to deliver secure code. Every PHP programmer has the responsibility to understand how attacks can be carried out against their PHP scripts to exploit possible security vulnerabilities. Reading this article, you’ll find out more about cross-site scripting attacks and how to prevent them in your code.

    Learning by Example

    Let’s take the following code snippet.

    Here we have a simple form in which there is a text box for data input and a submit button. Once the form is submitted, it will submit the data to post.php for processing. Let’s say all post.php does is output the data like so:

    echo $_POST["comment"];

    Without any filtering, a hacker could submit the following through the form which will generates a popup in the browser with the message “hacked”.


    This example, despite its being malicious in nature, does not seem to do much harm. But think about what could happen in the JavaScript code was written to steal a user’s cookie and extract sensitive information from it? There are far worse XSS attacks than a simple alert() call.

    Cross-site scripting attacks can be grouped in two major categories, based on how they deliver the malicious payload: non-persistent XSS, and persistent XSS. Allow me to discuss each type in detail.

    Non-persistent XSS

    Also known as reflected XSS attack, meaning that the actual malicious code is not stored on the server but rather gets passed through it and presented to the victim, is the more popular XSS strategy of the two delivery methods. The attack is launched from an external source, such as from an e-mail message or a third-party website.

    Here’s an example of a portion of a simple search result script:

    // Get search results based on the query
    echo "You searched for: " . $_GET["query"];

    // List search results

    The example can be a very unsecure results page where the search query is displayed back to the user. The problem here is that the $_GET["query"] variable isn’t validated or escaped, therefore an attacker could send the following link to the victim:“hacked”)

    Without validation, the page would contain:

    You searched for: alert(“hacked”)

    Persistent XSS

    This type of attack happens when the malicious code has already slipped through the validation process and it is stored in a data store. This could be a comment, log file, notification message, or any other section on the website which required user input at one time. Later, when this particular information is presented on the website, the malicious code gets executed.

    Let’s use the following example for a rudimentary file-based comment system. Assuming the same form I presented earlier, let’s say the receiving script simply appends the comment to a data file.

    file_put_contents("comments.txt", $_POST["comment"], FILE_APPEND);

    Elsewhere the contents of comments.txt is shown to visitors:

    echo file_get_contents("comments.txt");

    When a user submit a comment it gets saved to the data file. Then the entire file (thus the entire series of comments) is displayed to the readership. If malicious code is submitted then it will be saved and displayed as is without any validation or escaping.

    Preventing Cross-Site Scripting Attacks

    Fortunately, as easily as an XSS attack can carried out against an unprotected website, protecting against them are just as easy. Prevention must always be in your thoughts, though, even before you write a single line of code.

    The first rule which needs to be “enforced” in any web environment (be it development, staging, or production) is never trust data coming from the user or from any other third party sources. This can’t be emphasized enough. Every bit of data must be validated on input and escaped on output. This is the golden rule of preventing XSS.

    In order to implement solid security measures which prevents XSS attacks, we should be mindful of data validation, data sanitization, and output escaping.

    Data Validation

    Data validation is the process of ensuring that your application is running with correct data. If your PHP script expects an integer for user input, then any other type of data would be discarded. Every piece of user data must be validated when it is received to ensure it is of the corrected type, and discarded if it doesn’t pass the validation process.

    If you wanted to validate a phone number, for example, you would discard any strings containing letters, because a phone number should consist of digits only. You should also take the length of the string into consideration. If you wanted to be more permissive, you could allow a limited set of special characters such as plus, parenthesis, and dashes which are often used in formatting phone numbers specific to your intended locale.

    // validate a US phone number
    if (preg_match('/^((1-)?d{3}-)d{3}-d{4}$/', $phone)) {
    echo $phone . " is valid format.";

    Data Sanitization

    Data sanitization focuses on manipulating the data to make sure it is safe by removing any unwanted bits from the data and normalizing it to the correct form. For example, if you are expecting a plain text string as user input, you may want to remove any HTML markup from it.

    // sanitize HTML from the comment
    $comment = strip_tags($_POST["comment"]);
    Sometimes, data validation and sanitization/normalization can go hand in hand.

    // normalize and validate a US phone number
    $phone = preg_replace('/[^d]/', "", $phone);
    $len = strlen($phone);
    if ($len == 7 || $len == 10 || $len == 11) {
    echo $phone . " is valid format.";

    Output Escaping

    In order to protect the integrity of displayed/output data, you should escape the data when presenting it to the user. This prevents the browser from applying any unintended meaning to any special sequence of characters that may be found.

    // escape output sent to the browser
    echo "You searched for: " . htmlspecialchars($_GET["query"]);

    All Together Now!

    To better understand the three aspects of data processing, let’s take another look at the file-based comment system from earlier and modify it to make sure it’s secure. The potential vulnerabilities in the code stem from the fact that $_POST["comment"] is blindly appended to the comments.txt file which is then displayed directly to the user. To secure it, the $_POST["comment"] value should be validated and sanitized before it is added to the file, and the file’s contents should be escaped when displayed to the user.

    // validate comment
    $comment = trim($_POST["comment"]);
    if (empty($comment)) {
    exit("must provide a comment");

    // sanitize comment
    $comment = strip_tags($comment);

    // comment is now safe for storage
    file_put_contents("comments.txt", $comment, FILE_APPEND);

    // escape comments before display
    $comments = file_get_contents("comments.txt");
    echo htmlspecialchars($comments);

    The script first validates the incoming comment to make sure a non-zero length string as been provided by the user. After all, a blank comment isn’t very interesting.

    Data validation needs to happen within a well defined context, meaning that if I expect an integer back from the user, then I validate it accordingly by converting the data into an integer and handle it as an integer. If this results in invalid data, then simply discard it and let the user know about it.

    Then the script sanitizes the comment by removing any HTML tags it may contain.

    And finally, the comments are retrieved, filtered, and displayed.

    Generally the htmlspecialchars() function is sufficient for filtering output intended for viewing in a browser. If you’re using a character encoding in your web pages other than ISO-8859-1 or UTF-8, though, then you’ll want to use htmlentities(). For more information on the two functions, read their respective write-ups in the official PHP documentation.

    Bear in mind that no single solution exists that is 100% secure on a constantly evolving medium like the Web. Test your validation code thoroughly with the most up to date XSS test vectors. Using the test data from the following sources should reveal if your code is still prone to XSS attacks.

    RSnake XSS cheatsheet (a pretty comprehensive list of XSS vectors you can use to test your code)
    Zend Framework’s XSS test data
    XSS cheatsheet (makes use of HTML5 features)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s