You’ve been using PHP for years, and it seems to work just fine, but have you ever wondered what more you could be doing to keep your scripts secure? As security breaches become more common and more destructive, there are a number of best practices you can implement in your scripts to make sure they’re safe from hackers of all levels. Here are ten ways you can improve your PHP security today, starting with the obvious ones and moving into slightly less-common areas that could save you from disaster in the future.
1) Change Default Ports
The majority of web servers run on ports 80 and 443. If your PHP application is exposed on either of these ports, you should change them as soon as possible to something like: 1141 (443) and 1142 (80). There are a few reasons for changing these ports. First, it makes it much more difficult for an intruder to gain access because most people would assume that both of these numbers have already been used up. Second, it prevents conflict with other services running on these ports. Third, some ISPs may block port 80/443 if they aren’t already in use—but just about any ISP will allow port 1143 or higher traffic through without restriction. Changing your default ports doesn’t mean that you shouldn’t put any security measures in place; they should still be implemented but on non-standard HTTP/HTTPS channels.
2) Use HTTPS at All Times
Many websites aren’t using HTTPS, even though they should be. It is important that your website be secure at all times by making sure you use HTTPS instead of HTTP. This will protect your data and personal information by encrypting it so that it cannot be read by others over an unsecured connection. HTTPS is especially important for sites that handle sensitive data like credit card numbers or health information; if someone intercepts your traffic, your data can easily become compromised.
3) Use Strong Passwords
There’s no reason not to use strong passwords that contain a mix of numbers, letters, and special characters. A great password should be long (ideally more than 12 characters) and contain at least one number and one symbol. And remember: These days it’s often safer to use two different passwords instead of using a passphrase. Make sure you use different passwords for your various logins; if someone finds out your login information for one site they can easily compromise your entire digital life with just a few clicks. Consider password managers like LastPass and KeyPass which allow you to store all of your passwords in an encrypted database that syncs across all of your devices.
4) Disable Remote Code Execution
If remote code execution is enabled, attackers can execute arbitrary code on your server. This should be disabled at all times. Because of its potential consequences, remote code execution should be one of your top priorities when securing a web application. Ensure that you have properly configured settings to disable it. Disable It For All Files If possible, don’t just disable it for .php files—disable it for all file types so that attackers can’t use other kinds of files as backdoors into your site. As an added bonus, turning off remote code execution will reduce your exposure to drive-by downloads and other kinds of malicious scripts loaded from untrusted sources on your website. Evaluate Third-Party Plugins Third-party plugins are notorious for being full of security vulnerabilities because they’re not subject to your usual quality control measures. Consequently, if you don’t develop custom functionality yourself, third-party plugins are very likely to contain mistakes that could cause security problems in your site. Consider using only high quality modules with track records of maintaining secure code or proprietary code developed in house by experienced developers with high levels of expertise in web application security. Check Web Server Configuration Options Although they aren't necessarily directly related to PHP vulnerabilities, there are certain configuration options within Apache which are good general practices in terms of security because they restrict what various processes running on your system are allowed or not allowed to do.
5) Enable ModSecurity or Other WAF
Even if you’re not a web application developer, one of your biggest responsibilities as an information security professional is helping developers implement secure coding practices. This is why it’s so important that you become familiar with WAFs, or web application firewalls, and learn how to enable them for your organization. Even a little bit of knowledge can go a long way towards making your organization more secure. For example, by enabling ModSecurity on all of your web servers (and Apache load balancers), you dramatically increase security—and peace of mind—for everyone involved.
6) Rely on Built-in Security Features
From safe_mode to open_basedir, there are lots of ways that you can improve your site’s security by taking advantage of built-in features. For example, if you’re creating a new file upload function, use validate_file_name() rather than doing it yourself. When in doubt, see what WordPress or another popular framework is doing. If their code doesn’t have an obvious vulnerability, yours probably won’t either. Don’t reinvent what has already been written. Use Built-In Functions: There are so many functions available for every language out there! Make sure you learn them and use them! Save time on trying to write something complicated when someone else has already solved it for you.
7) Don't Run Admin Tools on Production Servers
Sure, running some administrative tools might be handy on your development server, but they're just asking for trouble if you run them on a production server. Tools like phpMyAdmin and Adminer give potential hackers an avenue of attack that, with enough knowledge and persistence, can lead directly to your database. Just don't do it. If you need remote access to your database for development or debugging purposes, use SSH tunneling instead. For MySQL users who want GUI access, check out LAMP stack offerings like PhpMyAdmin Lite or Adminer; both are solid alternatives that offer good data security practices. Or better yet, stick with command-line access so you can completely protect your data from any malicious intent by placing crucial connections outside of a Web environment. Think again before allowing passwordless accounts: It may seem convenient for a developer to set up a root account without a password on his local dev box—but that's exactly why many security pros warn against using them in production environments. When databases aren't secured properly, anyone who has login information can easily exploit SQL Injection vulnerabilities as well as run commands as any user they want (even as root). Even worse, those same people could potentially work their way through sudo permissions all the way up to root once access is granted via login credentials.
8) Check Third Party Libraries Before Use
If you use any third-party libraries in your application, such as those that parse uploaded files, then it’s extremely important that you first check these libraries for known vulnerabilities. While it might be easier to use a pre-written library than spend time writing your own parsing code, we can never guarantee we won’t introduce new security vulnerabilities by relying on external code and will only improve our application’s security if we check everything before we integrate it into our project. Find out more: How to audit third party libraries for security flaws.
9) Move Configuration Files Out of Web Root
These files can contain all sorts of sensitive data, including MySQL passwords. If a hacker obtains access to these files through a vulnerability in your application, it’s as easy as modifying a few lines of code and running a single command. Keep configuration files out of web root by placing them outside your website’s document directory—in wp-content/config , for example. Better yet, put them on another server entirely. If you use continuous integration tools like Gitlab CI or Github, place config files on a private repository and don’t push those repositories to public servers. Then set up an automated process that updates config files each time you deploy new code.
10) Keep PHP Up To Date
Keeping your code up-to-date is a surefire way to make sure you aren’t vulnerable to known vulnerabilities. If you’re building something from scratch, try using Composer for dependency management; it can be integrated with GitLab CI for automated deployments. If you’re working on an existing project or want to add one line of code at a time, don’t forget about git diff and git pull requests; these features make it easy to ensure everyone knows what they’re getting into when updating their local environments or files. You might also consider creating a process that requires people to review and sign off on any changes. Ultimately, knowing who made changes and when (and how) will help you track down vulnerabilities sooner instead of later. Don’t wait until someone tells you there's a problem—take precautions proactively! And speaking of notifications: never miss them again with GitLab Issue Notifications or Mattermost Notifications.
Top comments (3)
Awesome post
I used to remember when content creators and bloggers say use nodejs or Django or one of those framework/tool because php is not safe. Personally, I know two people that wrote very secure core php code and didn't rely on third party lib.
They preferred php over other tools until recently where the job dictates the tools.
This is what I can add..
On a server:
Thanks for the informative blog post! I would like to add a few supplementary points that may benefit your readers:
Hi there, nice article - just a few thoughts:
While it sounds like it might help, changing the ports that your web application runs on doesn't add that much security-wise (it's the idea of "security through obscurity"). In fact, I'd go so far to say that changing the ports to something non-standard for web applications could cause more problems than help anything as a lot of services and software just assume 80 and 443 as the ports to use.
The "Disable Remote Code Execution" section is a bit confusing (it looks like maybe formatting got messed up somewhere), but you seem to be misusing the term "remote code execution" (RCE). RCE is a security vulnerability where the attacker can use functionality in your software to run their own code on your system. You can't "disable" this as it's not really a feature. There also seems to be some overlap between this section and the ideas in the "Check Third Party Libraries Before Use" section.
In "Don't Run Admin Tools on Production Servers" you mention SQL injection vulnerabilities but connect it to the attacker having the database credentials. SQL injection is when a security flaw in the software (web application) is used to execute user-defined SQL, not via direct database access.