Brief introduction
PHP as a powerful language, whether it is installed in a modular or CGI way, its interpreter can access files on the server, run commands and create network connections. These features may add a lot of insecurity to the server, but as long as you install and configure PHP correctly, and write secure code, PHP can create a more secure CGI program than Perl and C. Also, a good balance can be found between usability and security.
PHP may be used in many different ways, so PHP has built-in options to make it easy for users to configure. While there are many options to make PHP do a lot of work, setting up these options and configuring the server is likely to create security issues.
PHP's options are as good as its syntax, with a high level of flexibility. With PHP, you can create a complete server-side program in an environment that has only shell user permissions, or use it in a tightly restricted environment to complete server-side containment (Server-side includes) without the risk of being too large. The security of how to build such an environment depends to a large extent on the developers of PHP.
This chapter begins with some general security recommendations on how to maximize security in different environments and describes some programming principles for different levels of security.
General
An absolutely secure system does not exist, so the methods commonly used in the security industry help to balance availability and risk. Two-way verification of each variable submitted by a user can be a responsible behavior, but it can result in a user having to spend a lot of time filling out a very complex form, forcing some users to try to circumvent the security mechanism.
The best security mechanism should be able to meet the needs without interfering with the user and not unduly increasing the difficulty of development. In fact, some security issues often occur on systems that are overly reinforcing security mechanisms.
Don't forget the famous principle of equal strength: the intensity of a system is determined by its weakest link (equivalent to the cask principle). If all transactions are recorded in detail based on time, location, transaction type, and user authentication relies on only one cookie, then the credibility of the transaction record for the user is greatly stripped.
When debugging code, it's important to remember that even a simple page can be difficult to detect for all the things that might happen: employees who are dissatisfied with you don't necessarily enter what you want, hackers have plenty of time to study your system, and of course your pet cat will jump on your keyboard. That's why you have to check all the code to find out where you can introduce inappropriate data and then improve, simplify, or enhance your code.
The internet is full of people who destroy your code for fame, attack your site, and enter inappropriate data--in short, they make your life fun. Whether it is a big website or a small website, as long as you can connect with the Internet, it will become a goal. Many hackers do not care about the size of the website, only mechanically scan the IP address and find the victim. We hope that's not you.