One of the most basic security mechanisms is file/folder permissions and ownership. Assuming that you are working on a Linux/Unix system, the main recommendation is to assign the ownership of your source code to the web server or PHP engine user. Regarding file permissions, you should be using the following setting:

Avoid any future problems by allowing the execution of PHP scripts only on selected paths and deny any kind of execution in sensitive (writable) directories, for example, any upload directories.

As a rule of thumb, never trust the user. Filter any input that comes from anybody, you never know the dark intentions behind a form submit. Of course, never rely only on frontend filtering and validation. If you added filtering and validation to the frontend, do it again in the backend.

Nobody wants their data to be exposed or to be accessed by someone who does not have permission and this type of attack against your application is due to bad filtering or validation of the inputs. Imagine that you use a field to store the name of the user that is not correctly filtered, a malicious user can use this field to execute SQL queries. To help you to avoid this issue, use the ORM filtering methods or any filtering method available in your favorite framework when you are dealing with databases.

This is another type of attack against your application and is due to bad filtering. If you allow your users to post any kind of content on your page, it may be possible for some malicious users to add scripts to the page without your permission. Imagine that you have a comments section on your page and your input filtering is not the best, a malicious user can add a script as a comment that opens a spam pop up. Remember what we told you before--never trust your users--filter and validate everything.

In this attack, the malicious user steals another user's session keys, giving the malicious user the opportunity to be like the other user. Imagine that your application deals with financial information and a malicious user can steal an admin session key, now this user can get all the information they need. Most of the time, sessions are stolen using an XSS attack, so first, try to avoid any XSS attacks. Another way of mitigating this issue is preventing JavaScript from having access to the session ID; you can do this in your php.ini with the session.cookie.httponly setting.

Including remote files from your application can be very dangerous, you will never be 100% sure that the remote file you are including can be trusted. If at some point, the included remote file is compromised, attackers can do what they want, for example, remove all the data from your application.

An easy way to avoid this is to disable the remote files in your php.ini. Open it and disable the following settings:

Never store any passwords in plain text. When we say never, we mean never. If you think that you will need to check a user's password you are wrong, any kind of restoring or resupplying a missing password needs to go through a recovery system. When you store a password, you store the password hash that is mixed with some random salt.

If you keep sensitive data and you don't want your application to be exposed by the passwords of your users, put a very strict password policy in place. For example, you can create the following password policy to reduce cracking and dictionary attacks:

Keep the source code out of sight of curious eyes, if for some reason your server is broken, all the source code will be exposed as plain text. The only way to avoid this is to only keep the required files in the web server root folder. As an addition, be careful with special files, such as composer.json. If we expose our composer.json, everybody will know the different versions of each of our libraries, giving them an easy way of knowing any possible bugs.

This kind of an attack tries to access files that are stored outside the web root folder. Most of the time, this is due to bugs in the code, so the malicious user can manipulate variables that reference files. There is no easy way to avoid this; however, if you use external frameworks or libraries, keeping them up to date will help you.

These are the most obvious security concerns you need to be aware of, but this is not an exhaustive list. Subscribe to security newsletters and keep all your code up to date to reduce risks to the minimum.