Part 5: PHP Security Mini Guide – PHP Security Tips

Tips for PHP Security


Never rely solely on client-side validation as it can be easily bypassed. For instance, an attacker can disable/remove any Javascript from the source code of a page and submit a form without any validation. If the script which accepts the input does not have any server-side validation, then it is possible that one of the vulnerabilities mentioned in this article can be exploited. A combination of both server/client-side validation is ideal.


As we have established there are numerous ways to make the same request or action. Blacklisting can in most cases be circumvented and sometimes it is very difficult to include every possible forbidden input. There are cases though in which blacklisting can be useful. For example, having a list of strings which are commonly used in attacks can help block automated bots/scripts. Blacklisting can be bad when being used as the only security measure.

Software Update

This cannot be stressed enough. In PHP security and as with all other forms of security, keeping software up to date is critical. Updates commonly include security fixes which patch various vulnerabilities (publicly known or not). Many companies have critical servers and services running on outdated operating systems for reasons such as compatibility issues of their applications with newer versions of software, ignorance about security or lack of policies. This however leaves their systems and services open to attacks.


It is very common for developers to search online to find answers/solutions to problems they are facing with their code or projects. This is perfectly normal, and it is one of the powerful characteristics of the internet. However, it is also common for people to copy whatever piece of code they find online just because it has a lot of votes or because it appears to be working. This is wrong for many reasons. There are numerous sources which have insecure or outdated code snippets and by using them you put your web application/server at risk. Another reason you should not blindly copy ‘ready-made’ code is that at some point you end up having a web application with different code blocks from different people and you have no idea how it works, why it works that way and if it’s working as it should. It is very important to spend time to study and understand how the mechanics behind the various functions or technologies you are interested in work. Not only will you be able to identify insecure or buggy code, but you will also write your own scripts in your own style. It is much easier to troubleshoot your own code than somebody else’s.

Rate limit + lockout

If you are building a web application which makes use of a login system or shows dynamic content based on user input, then you should consider implementing rate limiting. Rate limit is when a system is configured to allow only a certain number of requests to be processed/served within a time window. For instance, to allow 10 requests to be made in 20 seconds. Depending on the case, if the limit is exceeded requests can be dropped, blocked, or queued. This can be particularly useful against brute force attacks on login forms where a very large number of requests is required to crack a password. It can also be useful to protect against other attacks as it will significantly slow down automated scanners, crawlers or bots which initiate hundreds or thousands of requests to identify vulnerabilities.

Slowing down an attacker can help; however, they might have all the time in the world to complete their attack. This is where a lockout comes in. In case of a login form, if an account has N amount of unsuccessful login attempts then it should be blocked for N amount of time. Combined with a notification system to alert an admin, this can mitigate various attacks effectively.

Strong password enforcement

In this series we have talked about the importance of password storage in web applications. It is equally important however the use of strong passwords by the administrators and the users. A web application should not allow users to define a weak password for their account as this would make its cracking easier. Even with a rate limit or lockout mechanism in place, if a password is extremely common or easy then it might be guessed within the allowed fail/rate limit.

Weak passwords

A password can be qualified as weak if it fits into one or more of the following categories:

  • Is too short (< 6 characters): e.x passme
  • Consists of only numbers: e.x 181759
  • Consists of only lowercase characters: e.x mypassword
  • Consists of only uppercase characters: e.x MYPASSWORD
  • Contains dictionary and/or common words: e.x football, house, dog, car
  • Is the software default: e.x admin, root, password
  • Has the letters or numbers in sequence: e.x qwerty123
  • Contain the username: e.x kevin1151 (username is ”kevin”)

Strong passwords

A strong password should

  • Be more than 8-10 characters
  • Contain a combination of uppercase characters, lowercase characters, numbers, and symbols in a random order
  • Not have repeated characters or a pattern
  • Not include common or dictionary words

Example of a strong password: 8a<:7],)>En1C$M{JH>08hv!s

Multi Factor Authentication (MFA)

MFA refers to the process in which a user must be authenticated against a system using more than one methods. The first and most common method of authentication is a password. However, passwords can be cracked/leaked or stolen. In MFA, a user needs to provide additional methods of authentication such as verification via email, telephone (sms or voice call) or token devices. This ensures that even if a user’s password is leaked, their account will not be compromised (unless the attacker has access to all the authentication methods the victim has setup). It is very easy to implement, and it should be considered when building a web application.


Logs is an extremely important part of a system. They can be used to troubleshoot errors, gather statistics, and provide an admin information regarding the health and security of an application. Monitoring the logs can be useful to understand what, when and why happened. It is recommended to keep daily logs of critical systems and applications and have them analyzed to identify malicious activities. Ideally, they should be backed up to a remote location to avoid tampering by an attacker in case the system is compromised. (Avoid storing logs in publicly accessible directories and make sure they have the correct permissions.)

How to check for PHP vulnerabilities

The best way to check whether your website & applications are vulnerable to PHP security attacks is by using a tool like Acunetix. Acunetix crawls your entire website and automatically checks for vulnerabilities and will indicate which scripts are vulnerable so that you can fix them. Acunetix will check for SQL injection, Cross-site scripting & 3000 other web vulnerabilities.