PHP Security: Fortifying Your Website- Power Tips, Tools & How to’s

July 6th, 2009

Defining PHP Security and It’s uses

PHP is the most popular web programming languages in use today due in large part to the fact that it’s a highly flexible syntax that can perform many functions while working flawlessly in conjunction with html – Plus it’s relatively easy to learn for beginners, yet it’s powerful enough for advanced users as well. It also works exceptionally well with open source tools, such as the Apache web server and MySQL database. In other words, its versatility is unsurpassed when compared to other scripting languages, making it the language of choice for many programmers.

Though many programmers and developers may be implementing PHP in their websites, the issue of PHP security is often overlooked when building a site. Insecure coding is rather common in PHP due to the fact that it’s such a forgiving language that will often “work” even when there are a few loose ends in the coding. These “loose ends” are what hackers are looking for, and in PHP, they’re not that hard to find. The key is for you to find them first, and to leverage PHP’s unique features to minimize your security vulnerability.

PHP Security involves minimizing programming errors as much as possible, and putting proper code in place to protect against possible vulnerabilities – Often times this means putting 2-3 “layers” of protection in place to guard sensitive data against hackers that could otherwise cause a catastrophic result if compromised. Developers call this principle of redundant safeguarding Defense in Depth, and this concept has been proven over the years to be an extremely effective defense against malicious attacks.

Types of Attacks

There are various types of attacks that PHP is particularly vulnerable to, and any website that sends or receives information is at risk of an attack – ranging from an annoyance to catastrophic – so it’s important to put the proper security in place to minimize the risk. The two main types of attacks are human attacks and automated attacks – Both of which can potentially devastate a website.

The most common type of human attacks are little more than annoyances and are common at file storage sites and forums, such as abusing file storage policy, defamation, lobbying at sites such Amazon or Yahoo Answers, and other similar abuse that doesn’t necessarily involve manipulation of your website’s source code. Humans can also find security holes that allow them to access source code and use it maliciously. This can potentially cause substantial damage to your website, so this is the type of human attack you should focus your efforts on.

Automated attacks are particularly dangerous because of their efficiency in using the power of automated scripts to wreak havoc on your website in a number of different ways. These attacks may slow down your site, access the error logs, manipulate the source code, or compromise sensitive information – The possibilities are seemingly endless. The most common, and notorious, type of automated attack are viruses and worm, which are slightly different in nature but are similar in the way that they can potentially harm a website.

The goal of PHP security is to minimize, and ultimately eliminate, the potential for both human and automated attacks by putting into place strategic lines of defense to eliminate access to your site by unverified users. The way you go about doing this is to target the most common types of PHP security breaches first, so that you make your website airtight against malicious attacks. So what are the most common types of PHP security breaches?

Most Common PHP Security Vulnerabilities

Experienced hackers know the most common types of security holes to look for in PHP, so it’s important to address these issues first. It doesn’t matter whether you’re a beginner or expert PHP programmer, every programmer makes mistakes now and then, and hackers will find it if you don’t first.

1. Register_Globals

Register_Globals makes writing PHP applications simple and convenient for the developer, but it also poses a potential security risk. This setting is located in PHP’s configuration file, which is php.ini, and it can be either turned on or off. When turned on, it allows unverified users to inject variables into an application to gain administrative access to your website. Most, if not all, PHP security experts recommend turning register_globals off.

For example take a look at the code snippet below. A user could append the end of a page’s url with ?admin=1 to basically force entry to administrative areas that would normally require a password.

PHP Security Post Image

With register_globals turned off, this type of forced entry isn’t possible. The good news is that PHP 4.2.0 has register_globals turned off as its default setting, and PHP 6.0.0 has actually removed the feature. While some developers frown upon this move because register_globals off makes programming in PHP slightly more time-consuming, but in terms of PHP security it’s a crucial step in the right direction.

So instead of relying on register_globals, you should instead go through PHP Predefined Variables, such as $_REQUEST. To further tighten security, you should also specify by using: $_ENV, $_GET, $_POST, $_COOKIE, or $_SERVER instead using the more general $_REQUEST.

2. Error Reporting

Error reporting is a great tool for diagnosing bugs and allowing you to fix them quicker and easier, but it also poses a potential security threat. The problem occurs when the error is visible to others on-screen, because it reveals possible security holes in your source code that a hacker can easily take advantage of. If display_errors is not turned off, or have a value of “0”, the output will appear on the end user’s browser – Not good for security! You do, however, want to set log_errors to on, and then indicate the exact location of the log with error_log.

Take a look at the table below from, which points out the recommended settings for both production and development instances of PHP web applications.

PHP Security Post Image

3. Cross-Site Scripting (XSS)

Cross-site scripting, or XSS, is a way for hackers to gather your website’s user data by using malicious markup or JavaScript code to trick a user, or their browser, to follow a bad link or present their login details to a fake login screen that instead of logging them in, steals their personal information. The best way to defend against XSS is to disable JavaScript and images while surfing the web, but we all know that’s nearly impossible with so many websites using JavaScript’s rich application environment these days.

To defend against XSS attacks, you need to be proactive – Don’t wait until your website has already been exploited. For instance, PHP applications that use form submission, or POST requests, are much less vulnerable than GET requests. So it’s very important that you spell out which variables and actions will be allowed as GET values, and also which ones must come via POST values. In a nutshell, defending against XSS involves controlling the user input at your site and making sure that it goes through a filtering process to ensure that it’s void of malicious code.

An example of filtering user input can be found in the snippet of code below that was taken from Pro PHP Security by Chris Snyder and Michael Southwell.

PHP Security Post Image

This relatively straightforward piece of code works by preventing html and JavaScript from being embedded in the input, which results in a completely safe version of the input. This is especially useful for comment sections of a blog, forums and other web applications that receive user input.

Also useful for protecting against XSS is a useful PHP function called htmlentities(). This simple function works by converting all characters in html to their corresponding entities, such as “<” would convert to “<” (without the quotes).

4. Remote File Inclusion (RFI)

This type of attack is relatively unknown amongst developers, which makes it an especially damaging threat to PHP security. Remote file inclusion, or RFI, involves an attack from a remote location that exploits a vulnerable PHP application and injects malicious code for the purpose of spamming or even gaining access to the root folder of the server. An unverified user gaining access to any server can wreak major havoc on a website in many different ways, including abusing personal information stored in databases.

A great example of an RFI attack can be found Here’s an exerpt from that page:

Imagine that at a file exists and our script is located at The attacker will do this request: This file will get executed when it is included and it will a write a new file to the disk.

The best way to secure your site from RFI attacks is through php.ini directives – Specifically, the allow_url_fopen and the allow_url_include directives. The allow_url_fopen directive is set to on by default, and the allow_url_include is set to off. These two simple directives will adequately protect your site from RFI attacks.

Other PHP Security Tools

While the most effective way to secure PHP web application is through accurate coding and vigilante monitoring of your site, there are other helpful tools out there that can help to quickly and easily point out possible vulnerabilities in your PHP coding. Here are three useful tools that can be beneficial to PHP developers:

– PhpSecInfo

PHP Security Post Image

This useful tool reports security information in the PHP environment, and best of all, it offers suggestions for improving the errors. It’s available for download under the “New BSD” license, and the PhpSecInfo project is always looking for more PHP developers to help improve this tool.

PHP Security Post Image

Download PhpSecInfo Here.

– PHP Security Scanner

This is a tool used to scan PHP code for vulnerabilities, and it can be used to scan any directory. PHP Security Scanner features a useful UI for better visualization of potential problems, and it supports basic wild card search functionality for filtering directories or files that are to be searched.

Download PHP Security Scanner Here

– Spike PHP Security Audit Tool

The Spike PHP Security Audit Tool is an open source solution for doing static analysis of PHP code. It will search for security exploits, so you can correct them during the development process.

PHP Security Post Image

Download Spike PHP Security Audit Tool Here

Author: Joel Reyes

Joel Reyes Has been designing and coding web sites for several years, this has lead him to be the creative mind behind Looney Designer a design resource and portfolio site that revolves around web and graphic design.

Write for Us! We are looking for exciting and creative articles, if you want to contribute, just send us an email.

The jungle is alive: Be it a collaboration between two or more authors or an article by an author not contributing regularly. In these cases you find the Noupe Editorial Team as the ones who made it. Guest authors get their own little bio boxes below the article, so watch out for these.


73 comments for „PHP Security: Fortifying Your Website- Power Tips, Tools & How to’s
  1. artmania on July 6th, 2009 at 3:22 am

    wow very useful! thanks!!!

  2. Anon on July 6th, 2009 at 6:07 am

    Some quick stuff:
    Turning off register_globals is not necessary for security. Instead, in the given example, the coder could have included admin=false in the top of the file, thereby nullifying any potential flaws.
    For XSS, a simple htmlspecialchars() command will sanitize the input (can’t XSS if you can’t open the script tag).

  3. Jake on July 6th, 2009 at 6:46 am

    the Register Globals setting is by far the most obvious and easily preventable security flaw I see in all sorts of PHP apps

  4. Permana Jayanta on July 6th, 2009 at 8:11 am

    Very useful to me, thaks for PHP security tools information

  5. John on July 6th, 2009 at 9:23 am

    You say that “there are various types of attacks that PHP is particularly vulnerable to.” I would just like to clarify that PHP itself isn’t vulnerable to these attacks – rather websites built using PHP are primarly due to incompetent programmers.

    That being said – very nice post!

  6. Laars Johnsen on July 6th, 2009 at 9:30 am

    For the love of god, dude, “IT’S” is a contraction of “it is”; “ITS” is the possessive form of “it.”

  7. Mike on July 6th, 2009 at 2:08 pm

    Am I thinking wrong? In my opinion, hint #3 doesn’t prevent XSS because the variables should be filtered directly. So I would write:

    $title = safe( $_POST[‘title’] );

    Otherwise, a hacker could infiltrate bad code because $title doesn’t filter the input.

  8. Simon on July 6th, 2009 at 2:14 pm

    Thanks a lot, that’s really usefull !
    By the way does anyone have a cheatsheet explaining the differencies between:
    and so on… ?
    Thanks again !

  9. ghprod on July 6th, 2009 at 2:58 pm

    really usefull post for me :)

    i want to know more about php attack so we can develop a better script :D

    btw u can go through to :)


  10. Simon on July 6th, 2009 at 3:07 pm

    Don’t worry I’m not the kind to ask before I took a look by myself.
    That’s why I was asking for a cheat sheet ;) A quick look on the sheet and you’re done.

  11. Frank West on July 6th, 2009 at 4:03 pm

    A simple to understand article covering important topics, a great article for the less experience.

  12. Arjen on July 6th, 2009 at 5:41 pm

    Thanks, I’m definitely going to check the security of my projects. Currently I’m busy with a WebOS, which needs to be as secure as possible.

  13. Max-VII on July 6th, 2009 at 6:24 pm

    When a variable, which is supposed to contain an integer, is incoming via POST or GET into a PHP script, it is the right thing to use casting.
    $a = (int)$_POST[‘a’];
    It is fast, it does not take resources, and serializes the variable containing an integer.

    • Ben D. on July 10th, 2009 at 12:58 pm

      Casting an unfiltered variable is never the right thing to do.

      Always filter data before processing it. You don’t know what’s in there.

      • k on March 2nd, 2010 at 6:24 am

        ..if you expect an integer, yes, it is a good thing to do.

      • Jim S. on April 17th, 2012 at 1:02 am

        I must agree here!

        If you are expecting your values to be numeric, then string values will simply return 0’s.

        Also generally a very good idea to get good with using preg_match(), and other similar regular expressions on your returned data. It may be that not all systems are as up-to-date enough to have “htmlentities” available to your scripts.

        – Just a thought.

        – Jim.

  14. Web Design Mumbai on July 6th, 2009 at 6:38 pm

    nice topic.

    thanks for shedding more light on this.

  15. Shahriat Hossain on July 6th, 2009 at 9:33 pm

    To filter and sanitize external data I like to use these two functions filter_var() and filter_input() which are best practices, so just go ahead with these best practices ;)

  16. Sambir Shrestha on July 6th, 2009 at 9:49 pm

    Another important Security issue in PHP is SQL injection. SQL injection attacks are extremely simple to defend against, but many applications are still vulnerable. Consider the following SQL statement:

    This query is constructed with $_POST, which should immediately look suspicious.

    Assume that this query is creating a new account. The user provides a desired username and an email address. The registration application generates a temporary password and emails it to the user to verify the email address. Imagine that the user enters the following as a username:

    bad_guy’, ‘mypass’, ”), (‘good_guy
    This certainly doesn’t look like a valid username, but with no data filtering in place, the application can’t tell. If a valid email address is given (, for example), and 1234 is what the application generates for the password, the SQL statement becomes the following:

    Rather than the intended action of creating a single account (good_guy) with a valid email address, the application has been tricked into creating two accounts, and the user supplied every detail of the bad_guy account.

    While this particular example might not seem so harmful, it should be clear that worse things could happen once an attacker can make modifications to your SQL statements.

    For example, depending on the database you are using, it might be possible to send multiple queries to the database server in a single call. Thus, a user can potentially terminate the existing query with a semicolon and follow this with a query of the user’s choosing.

    MySQL, until recently, does not allow multiple queries, so this particular risk is mitigated. Newer versions of MySQL allow multiple queries, but the corresponding PHP extension (ext/mysqli) requires that you use a separate function if you want to send multiple queries (mysqli_multi_query() instead of mysqli_query()). Only allowing a single query is safer, because it limits what an attacker can potentially do.

    Protecting against SQL injection is easy:

    Filter your data.

    This cannot be overstressed. With good data filtering in place, most security concerns are mitigated, and some are practically eliminated.

    Quote your data.

    If your database allows it (MySQL does), put single quotes around all values in your SQL statements, regardless of the data type.

    Escape your data.

    Sometimes valid data can unintentionally interfere with the format of the SQL statement itself. Use mysql_escape_string() or an escaping function native to your particular database. If there isn’t a specific one, addslashes() is a good last resort.

    • Joel R. on July 7th, 2009 at 2:15 am

      Thank you all for your comments! They are much appreciated!

      If you have any questions, please feel free to ask.

    • Ben D. on July 10th, 2009 at 1:09 pm

      Good points, but it’s helpful to distinguish between different kinds of data. Input should be filtered; output should be escaped.

      I’m not sure about “Quote your data”, either, in the context of SQL. It’s a good practice if you’re doing something like:

      query(“SELECT * FROM table WHERE id=’$id'”);

      But you shouldn’t be doing something like this. Instead you should be binding parameters (psuedo-code follows):

      $sql = “SELECT * FROM table WHERE id=?”;
      execute($sql, array($id));

      This keeps your data totally separate from your query. The ability to bind parameters is built in to PHP 5’s PDO class.

    • ottoman on November 17th, 2010 at 12:43 pm

      I am new and very inexperience with php and web programming. So please help if you could.

      This question is about SQL injection:

      If I have an input which can only be a 4-digit postcode. This postcode is used to run an MySQL query. Since i know it needs to be numbers only and must be 4 digits in lenght (make size = 4), then I can simply check the input to make sure it is valid before running the query, otherwise, I prompt user to re-enter a valid postcode.

      Is this good enough? Or am I still running a risk of SQL injection?

  17. Pablo Livardo on July 7th, 2009 at 2:45 am

    All PHP vulnerabilities are due to programming errors; the language is not itself vulnerable. Most of these vulnerabilities are based on inadequate filtering of input whether it’s from the URL or posted data.

    PHP frameworks can assist greatly with this onerous task and would be highly recommended for any production site. KohanaPHP and CodeIgniter are two I’d recommend but their bare-minimum approach may not suit your own programming abilities.

    Alternatively, make sure you have a good backup. A cron job that dumps your database and a scheduled rsync or FTP dump would be well-advised. It’s kept me out of hot water for many years even when my programming skills let me down.

    • Ben D. on July 10th, 2009 at 12:56 pm

      “All PHP vulnerabilities are due to programming errors; the language is not itself vulnerable”

      Not true, else why would the PHP team be constantly releasing new versions with security fixes.

      Maybe what you meant was that PHP itself is no more or less secure than any other programming language?

  18. devnull on July 7th, 2009 at 5:38 am

    Hardened PHP has tools to help secure PHP. And mod_security on the web app side to secure the web frontend.

  19. jo on July 8th, 2009 at 1:02 am

    I’d also recommend turning off your php version info in the http headers to avoid someone possibly targeting a known vulnerability.

    expose_php Off

  20. e11world on July 8th, 2009 at 2:28 am

    I’m a bit of a beginner still in PHP. Wondering about logins (using php4 i guess). If I have a page.php that has a form with a login, this info will be passed on to page2.php where the username/passwords are stored (Can’t use MySQL DB for this sample so go along), is this safe? What is a better way of doing this?

  21. Latest Tech news on July 8th, 2009 at 2:55 am

    Thanks for sharing valuable knowledge :)

  22. Jonathan Nicol on July 8th, 2009 at 6:56 am

    I’m surprised this post didn’t mention SQL Injection, which to my knowledge is one of the most common and widely exploited PHP security vulnerabilities.

    As mentioned in the article, since PHP 4.2.0 register globals has been turned OFF by default, and I would be surprised if any responsible web host has it turned on.

    Another security vulnerability to consider is email header injection, which exploits the mail() function to hijack a website’s contact form for the puspose of sending spam email.

  23. Csaba on July 9th, 2009 at 2:45 am

    I like the security tools section of this post. Will try them for sure.

  24. Thai_guy on July 9th, 2009 at 9:01 am

    Hey this is fantastic stuff… I have sent it through our development group and asked for a report on the security tools mentioned. We would have loved to stumble on this article about 2 years ago but it is great information for those who are venturing into PHP.

    BTW the SQL injection comment is brilliant, this page will be saved in many developers Favorites files.


  25. x-ecutioner on July 9th, 2009 at 11:57 pm

    hey thanks so much for posting this, i really appreciate it

  26. Mike on July 10th, 2009 at 8:04 am

    For #3 (XSS), you completely omitted the idea of cleaning user input, which I expected to see on this list.

    For instance, if:
    $title = $_POST[‘title’];
    was only meant to be text, why not remove things you don’t allow?

    $title = preg_replace(‘/[^a-z\d\,\s/i’, ”, $_POST[‘title’];
    will allow only alphanumeric characters, spaces and commas. Now there’s nothing to worry about since any characters that could break our code are now gone.

    • Ben D. on July 10th, 2009 at 1:12 pm

      This is good, but it would be even better to use PHP’s “filter” functions:

      filter_input() would be the right one for the job of extracting a POST variable. The function has the added benefit of bypassing those evil magic_quotes if they happen to be turned on and you can’t turn them off.

    • Roy Arisse on August 17th, 2009 at 7:45 am

      Sanitizing is the best practise, but keep in mind that your code has to be ‘leightweight’ (at least in my opinion). So, only use regular expressions when you exacly know the format needed. Don’t ‘automagically’ remove stuff the user typed in, because then the result would be an unexpected one.
      Then, the next step would be preventing to rely on fallback values (ex: when $_POST wasn’t set at all, php will throw a notice and fall back to an empty array). This can be fixed easily; so I’ve done it for a few datatypes:

      // check for nummeric value
      $nummeric = !empty($_POST[‘nummeric’]) ? (int)$_POST[‘numeric’] : 0;

      // check for string
      $string = !empty($_POST[‘string’]) ? (string)$_POST[‘string’] : ”;

      // email (regex isn’t valid!)
      $emailaddress = !empty($_POST[’email’]) && preg_match(‘/\w+@\w+.\w+/’, $_POST[’email’]) ? $_POST[’email’] : ”;

      // known set of options? like gender:
      $allowed_genders = array(‘unknown’, ‘male’, ‘female’);
      $gender = !empty($_POST[‘gender’]) && in_array($_POST[‘gender’], $allowed_genders) ? $_POST[‘gender’] : $allowed_genders[0];

      Further, it’s important to know that user data should always be checked before put into queries eg. Don’t expext that a user knows a ‘ or ” could cause harm. There are several ways of making them harmless, but how to do so, is depending on the goal of the data.
      Here are some ways with their use:

      // Remove entirely
      $not_allowed_chars = array(‘\”, ‘”‘);
      $data = str_replace($not_allowed_chars, ”, $subject);

      // escape (‘ => \’)
      $data = addslashes($subject);

      // Encode (mind ENT_QUOTES)
      $data = htmlspecialchars($subjecy, ENT_QUOTES);

      Well, I hope this helps a bit ;)

  27. Mike on July 10th, 2009 at 8:08 am

    While SQL injection was beyond the scope of this article, since it’s as much an SQL problem as it is a PHP one, my comments on data cleansing above using preg_replace will prevent SQL injections as well.

    • Ben D. on July 10th, 2009 at 1:18 pm

      preg_replace() might prevent SQL injections. Or it might not, in certain cases. Your example regex permits whitespace and commas, for example, which could wreak havoc in poorly-written SQL-related code.

      I would suspect that, where possible, it’s better to branch to an error path when the code encounters invalid content, rather than trying to cleanse the data.

  28. AppleByte on July 10th, 2009 at 9:07 am

    This is very helpful resource. Thanks…

  29. Stephan on July 10th, 2009 at 8:13 pm

    htmlspecialchars() escapes a sub-set of htmlentities() and is therefore much faster than htmlentities(). For escaping user input data, htmlspecialchars() is usually preferred.

    ENT_QUOTES is really the kicker in preventing XSS in that you are specifically telling the function to escape double/single quotes.

    The final param is your charset. UTF-8, etc.

    If you want to test your forms against XSS, just google ‘XSS Cheat Sheet’…

    • Ben D. on July 10th, 2009 at 8:37 pm

      @Stephan: “htmlspecialchars() escapes a sub-set of htmlentities() and is therefore much faster than htmlentities()”

      Do you have a reference for this, or have you benchmarked it yourself? Just wondering because, depending on how the functions are implemented in the PHP core, that might not actually be true.

      If I’m escaping output I’m going to use htmlentities() because it’s more thorough and therefore more secure. If my code is performing meaningfully slower because I’m using htmlentities(), then I probably need to re-factor my code — not replace one core function with another that’s potentially less secure.

      • Stephan on July 16th, 2009 at 11:37 pm

        htmlentities translates ALL html chars and non-english language characters. htmlspecialchars sub-set is smaller. The number of iterations over the translation tables needed is much smaller than with htmlentities. You can see the difference by outputting the two translation tables with the following:

        echo var_dump( get_html_translation_table( HTML_SPECIALCHARS ) );


        echo var_dump( get_html_translation_table( HTML_ENTITIES ) );

        Using htmlentities or htmlspecialchars isn’t the only step in preventing XSS. However, if you are looking to translate html chars simply for XSS within the logic of your user input filtering, htmlspecialchars provides the necessary means to do this (with escaping single/double quotes).

        I agree though, in most cases using htmlentities vs htmlspecialchar will not vary much in terms of performance.

      • Ben D. on July 18th, 2009 at 9:37 am

        Just took a look at the PHP core code and I think you’re right, htmlspecialchars() has got to perform better than htmlentities().

        It’s not because of the size of the translation tables, though. Turns out that, in the underlying C code, there are separate maps for the “basic” characters covered by htmlspecialchars(), and for the higher-value characters covered by htmlentities().

        If you call htmlentities(), each character in your string gets checked against both maps.

        But if you call htmlspecialchars(), each character only gets checked against the “basic” map.

        So yes, many more CPU cycles consumed by htmlentities(). Does it make a significant difference at the PHP level? I guess that would depend on the PHP app.

  30. on July 11th, 2009 at 9:06 am

    Thanks for a great post. I like keeping posts like these archived. Register globals is a killer.

  31. Aaron McGowan on July 12th, 2009 at 1:45 pm

    With PHP 5.3 released, your error_reporting bit flag should be E_ALL | E_STRICT for development purposes.

  32. ghprod on July 12th, 2009 at 10:32 pm


    Can u give us example how to thread SQL Injection well?


    • Ben D. on July 14th, 2009 at 2:34 am

      @ghprod, what do you mean by “thread”?

  33. strony internetowe on July 13th, 2009 at 1:41 pm

    Nice, very nice. I dig it

  34. Jenny Miller on July 28th, 2009 at 4:41 pm

    This is an excellent post. thanks a lot!

  35. Bulungetong pugis on July 29th, 2009 at 2:31 pm

    Nice. Very helpfull post.

  36. Lotus24 on July 29th, 2009 at 2:50 pm

    Hey there :) this is an awesome post. But I would like to you all to use x-debug before making your project live. You can install x-debug for PHP, a debugging tool and can encounter any errors in staging phase itself.

  37. Mapics on August 3rd, 2009 at 7:08 pm

    Très bon article, très intéressant. Merci pour toutes ces ressources !

  38. Magali Wages on December 23rd, 2009 at 6:39 pm

    Kicking off 2010’s mixed martial arts is the brilliant UFC 108. It’s definitely going to be a great event with the kickoff being Evans vs Silva going head to head. You can watch evans vs silva video for FREE in full HD without paying that grotty $55.95 PPV cost.

  39. Ignace Knops on January 28th, 2010 at 4:01 am

    There is an error in the above safe() function:

    function safe($value) {
    htmlentities($value, ENT_QUOTES, ‘utf-8’);
    return $value;

    Returns $value as-is instead of filtering as htmlentities does not take it’s parameter by reference. The correct could be:

    function safe($value) {
    return htmlentities($value, ENT_QUOTES, ‘utf-8’);

    • Jim S. on April 17th, 2012 at 1:16 am

      All you really did was remove one step from your code.

      Not that this is a BAD thing, but you really didn’t change the logic of your function any.

      – Jim

  40. fandhie on March 3rd, 2010 at 10:25 am

    thanks for this great article
    it’s very useful for a newbie like me :)

  41. the_guv on May 26th, 2010 at 3:37 am

    very nice Joel .. thank you

    • Priest on June 23rd, 2011 at 12:26 pm

      To think, I was confused a mitune ago.

  42. ryan on August 12th, 2010 at 11:38 pm

    very useful to me, thanks

  43. Zachary Roach on August 28th, 2010 at 10:46 pm

    I search the topic in these days. At last I am luck to find your blog. I love your web page! did you create this yourself or did you outsource it? Im in search of a blog design thats similar so thats the only cause I’m asking. Either way keep up the great work I was impressed with your content genuinely. BTW, could I use your thread on my blog or could we do links exchange? Have a good day. My blog is Blackberry Phone Guide

  44. jack on November 16th, 2010 at 5:14 am

    Very Good site and useful!

  45. Carl on December 4th, 2010 at 1:02 pm

    Very usefull information, thanks for sharing.

  46. Shelby Hannegan on January 4th, 2011 at 1:10 am

    Could not concur far more with that, extremely interesting report. Thanks.

  47. Shaunte Dahlquist on January 18th, 2011 at 8:10 am

    Sorry to hear that.

  48. Bari on January 18th, 2011 at 8:25 am

    Hey there, You’ve done an excellent job. I’ll definitely digg it and personally suggest to my friends. I’m sure they’ll be benefited from this web site.

  49. Teddy on January 18th, 2011 at 9:00 am

    Many people are making money through blogging.Are you blogging for money now?I find that this blog ( shares many useful tips.

  50. Seeds Weed on January 18th, 2011 at 10:39 am

    Attractive section of content. I just stumbled upon your site and in accession capital to assert that I get in fact enjoyed account your blog posts. Anyway I will be subscribing to your feeds and even I achievement you access consistently quickly.

  51. SOHAN on March 31st, 2011 at 5:23 pm

    Great Fundas of PHP…..
    Learned all most Everything about PHP….

  52. Sophie on April 12th, 2011 at 5:18 pm

    Extremely useful! Thank you so much!

  53. Terri Bugler on April 14th, 2011 at 3:33 am

    I’m glad I chose to read this one. Nice work!

  54. click here on May 8th, 2011 at 12:03 am

    I just noticeed you haven’t written any posts in a while?

  55. Calvin Murrill on May 19th, 2011 at 11:59 am

    Have you ever thought about publishing an e-book or guest authoring on other websites? I have a blog centered on the same subjects you discuss and would love to have you share some stories/information. I know my visitors would appreciate your work. If you’re even remotely interested, feel free to send me an e mail.

  56. Jayapal Chandran on January 4th, 2012 at 11:01 am

    Nice that i got this as first search result in google when i typed php security tips.
    This is really good information and i have not known about the last hack RFI.
    What about session hijacking?
    Hope you can expand this tutorial by including some more hacks and preventions. :)

  57. Jim S. on April 17th, 2012 at 1:07 am

    Maybe a comment on the “.htaccess” file?

    Making sure those settings are up-to-date by including severe restrictions on your data-containing folders, and any subfolders that hold your administration modules is in order?

    I always believe in using ALL security features together on your server.

    Disabling all JavaScripts and images for every web page may not be the way to go these days! Many sites will only display properly if you allow THEIR scripts and images ( as well as “styles” ) to load. So this may be a method that will backfire on the user, especially for some e-commerce sites.

    – Just another “stray thought”.

    – Jim