Common Mistakes PHP Developers Make

 

Undefined Variable

When you declare a variable in a function, it is only available to that function. If an operation requires the variable outside of the scope of the function that declared it, then you must pass that variable as a parameter to the function or use global.

Using global variables is not recommended because they can cause conflicts if another part of the program is using them for other purposes. It's better to pass the variable as a parameter instead.

Not Using $_SERVER['PHP_SELF']

Using $_SERVER['PHP_SELF'] is more efficient and will give you the value of the current script name. However, it's a bad practice to use because anyone may be able to input data into $_SERVER['PHP_SELF'], thus running arbitrary code in your script. For example, if a script called test.php contains the line echo $_SERVER['PHP_SELF']; and someone visits example.com/test.php/%22%3E%3Cscript%3Ealert('hacked')%3C/script%3E, this will output "/test.php/">alert('hacked')" to the browser, thereby executing alert('hacked').

Not Using get_magic_quotes_gpc()

The get_magic_quotes_gpc() function returns a boolean value. It can be used in PHP to determine whether or not the 'magic_quotes_gpc' directive is 1 or 0. This function is useful for checking the value of magic quotes and appropriately using addslashes() throughout your code.

For example, you might want to use it if you are writing user generated content to a database, which might involve one of these functions: addslashes(), mysql_real_escape(), or mysqli::real_escape(). Here's how you'd use it:

No Error Logging

The first step toward fixing your PHP errors is actually knowing what they are. To do this, you'll need to log them. Here's how:

Open up the php.ini file located in your server root directory. Find the error_log directive and set it to a file path where you want the error log to reside (relative and absolute paths are allowed). Remember that if this path is relative, it must be relative to your server root, not your website's public root (e.g., /var/log/php-errors.log). Specify the level of error reporting by setting another directive called error_reporting equal to one of these predefined E_STRICT constants; for example, E_ALL will report every type of error possible (including notices and warnings), while E_ERROR will only report fatal errors (i.e., errors that cause script execution to abort). Lastly, if you need more detail than simply viewing all logged errors in a single text file, consider setting up an analytics tool like Loggly or Splunk.

Once you've got some data logged on errors, here's how you can analyze it:

Not Using Prepared Statements to Prevent SQL Injection

Does it feel like every time you write a PHP app, five people have to tell you about SQL injection? For good reason: it’s an exploit that can be devastating for your application if left undetected. And let’s face it—it’s not easy to detect this sort of problem in the first place. That’s why learning how to do so can be a major asset for your developer toolkit.

If you've never used prepared statements before, they might seem like a bit of a challenge. But with practice, they'll become second nature, and you won't be writing code without them anymore!

It's really easy to prevent SQL injection using PHP's mysqli_ prepare() function. All you need to do is pass in the query and then call mysqli_stmt_bind_param() with the appropriate variable types for each parameter that needs sanitizing (including NULL).

With those two simple steps, your code will now prevent any malicious input from being passed into your database!

Not Using isset() Function

The isset() function is used to check whether a variable is set or not. If a variable is already unset with unset() function, it will no longer be set. The isset() function return true if testing variable contains a value, otherwise it return false. In addition, you can use empty(), which returns false if the tested variable exists and has a non-empty, non-zero value (or if the tested array contains at least one element). There are two common mistakes that PHP developers make:

1 - The first mistake is when they check the existence of any variables(superglobal $_POST, $_GET etc) or any other class property via isset(). This leads to unexpected results during many operations like unset(), issue with magic methods(__isset(), __unset()) etc. For example:

Avoid these common errors to make your PHP more secure and reliable.

It's important to know that the PHP language is not as secure as it should be. Many people make the mistake of assuming that it's completely safe and there's no need for any sort of defensive coding. In fact, over half of all websites are at risk from a variety of attacks because they don't take proper precautions when interacting with sensitive data. This includes 'regular' SQL injection attacks, cross-site scripting (XSS) attacks, and command injection attacks. If you don't take steps to protect your site, your users will put their trust into you, and they'll wind up with much more than they bargained for.