← Back to changelog

19 New PHP Checks

Last Tuesday we announced 8 new PHP checks, and promised more were on the way.

Today, we’re releasing 19 new checks, which identify security, logical and clarity issues in your PHP code. Each new check is outlined below, by category.

Security

  • Changing PHP configuration dynamically

    Some PHP functions are able to dynamically change properties of the system while running. Doing so can make assumptions about the structure and configuration of the running environment, limiting portability and creating potential security and performance issues.

  • Using debug functions

    The information provided by debugging functions may inadvertently make private information public, which is a security risk.

  • Changing the error display levels at runtime

    The error reporting level should not be changed at runtime as a consistent method should be used throughout your application to prevent accidental data leakage.

  • Using echo with file_get_contents

    The file_get_contents function reads the contents of a file into a string. Because this requires accessing files on the server’s file system, it is already necessary to use caution when using this function in application code. When combined with the echo function, code that has been read from the file system with file_get_contents is now being displayed, which creates a security risk.

  • Using *parse_str functions

    While these are convenient for evaluating query parameters into in-memory variables, these functions have potential security and clarity issues and should be avoided where possible.

  • Usage of the pass thru command

    This method should be very selectively used because of potential security and performance issues.

  • Using /e in regular expression modifier

    The /e regular expression modifier has been deprecated for security reasons. Using it has the dangerous side effect that the resulting string from the regular expression is evaluated as code.

  • Using the superglobal $_REQUEST

    Since this variables combines various data from user input, it can lead to data loss as well as Delayed Cross Site Request Forgery and Session Fixation vulnerabilities.

  • Usage of script-delaying functions

    Delaying the completion of a script opens your system up to Denial of Service (DoS) attacks as it ties up server resources for the duration of the script, putting you at risk for exceeding your available PHP processes, database connections, and other server resources.

  • Usage of the system command

    This method should be very selectively used because of potential security and performance issues.

Bug Risk

  • Not using the identical operator when comparing booleans

    Failure to use the comparison operator (===) when comparing booleans can lead to unexpected results.

  • Usage of exit or die

    Usage of these calls tends to result in poor user experience, hard to re-use code, and in some cases, inadvertent exposure of sensitive information.

  • Use of deprecated $http_raw_post_data

    Code that relies on $http_raw_post_data will eventually fail in future versions of PHP. Additionally, because $http_raw_post_data depends on a special ini directive in order to be populated, using it decreases the portability of your program.

Clarity

  • Using more than one Class per file

    Keeping one class per file ensures a clean, understandable file structure

  • High cyclomatic complexity

    Cyclomatic complexity correlates the number of potential pathways through a given unit of code with complexity - a unit of code with a lot of potential pathways will have a high cyclomatic complexity score.

  • Long classes

    The longer a class is, the harder it is to break down, test, and adequately express with a great name. Classes that are long will grow over time and become harder to manage, so it is usually a worthwhile investment to simplify classes by refactoring into smaller, more discrete units of functionality.

  • Long methods

    Methods that are too long are error prone, hard to understand, difficult to test, and tend to grow in size over time. All of these issues are design related and documenting, testing, and breaking down large methods into smaller ones is one of the best ways to simplify class structure and clarify design.

  • Long variable names

    Using excessively long variable names makes code difficult to scan easily and can be confusing. Long variable names are also a hassle to type and are prone to typos.

  • Short variable names

    Short variable names convey too little information at best and are confusing or error prone at worst. Using an abbreviated or meaningless name for a variable destroys its intent-conveying purpose, which can make code difficult to read and debug.

More PHP Checks

Actionable metrics for engineering leaders. Try Velocity Free