John Squibb

Error Reporting is a Developer's Best Friend

It is all-too-common to see weak levels of error reporting in development environments, which is unfortunate, because proper error reporting is not only one of the best debugging tools available to a developer, but also an excellent way to reveal significant security flaws in code before they become a threat in the real world.

Enabling Error Reporting

There are a couple of ways to adjust the error reporting levels in our applications, either at runtime, or from inside the configuration file, php.ini.

If you don't have access to your .ini file in a shared hosting environment, then the best way to adjust the error reporting is from within code, using the error_reporting() function.

If you do have access to the php.ini on your server, then you can use the error_reporting directive inside that file to establish different levels.

Whichever method you choose relies on the display_errors setting in the php.ini. You may have to consult your system admin or hosting provider to establish the appropriate setting if you do not have access to the .ini on your server.

Selecting the Appropriate Level of Error Reporting

It is important to choose the correct level of error reporting for our environment. We don't really want to tell the whole internet that our application has failed, as this would expose potentially sensitive data while also making us look like amateurs! In development environments, such as on our local development machines, or behind company firewalls, outsiders cannot see the errors, so we can usually display them without concern. The general rule is to display as many errors as possible in development, and as few as possible in production.

A good level of error reporting in development is E_ALL, but for the best possible adherence to proper coding standards, E_STRICT can provide the best level of output, as it enforces strict standards, and will warn against the use of deprecated functions. E_STRICT is an additional flag to E_ALL, and can be used like so:

error_reporting(E_ALL | E_STRICT);

Use Strong Error Reporting for Better Security

A lot of developers will use E_WARNING instead of E_ALL or E_STRICT mode, because they don't like to deal with the extra output generated by the stricter levels. Such developers will often disable notices altogether, using error_reporting(E_ALL & ~E_NOTICE). Don't be this kind of developer!

Notices are thrown, because PHP is trying to warn us that we are doing something incorrectly. Granted, E_STRICT and E_ALL will generate a lot of notices when we don't properly intialize variables, or when we forget to put quotes around array elements, or when we introduce typos in our code. This is exactly why we want to use stricter reporting! A simple typo or undefined variable in development can leave a bug or security hole in production code. Consider the following snippet:

In this example, it would be very easy to miss the typo 'acces_granted', and with error reporting disabled, the code would let us go right on missing it forever. The user would be granted access to the top-secret info, creating an unforgivable and preventable breach of security. With error_reporting(E_ALL), we would have received the following error in development, fixed the typo, and prevented the bug:

PHP Notice: Undefined variable: acces_granted in top_secret_stuff.php on line 11

Error Logging

When launching code into production, we want to squelch any error output, however, we would still like to know when things go wrong.

The php.ini directive log_errors allows us to turn error logging to 'On'. We can then specify a file to log errors to with error_log, and disable the display of errors on the page with display_errors 'Off'.

Here is an example of some possible settings in our php.ini:

; display_errors
;   Default Value: On
;   Development Value: On
;   Production Value: Off

; display_startup_errors
;   Default Value: Off
;   Development Value: On
;   Production Value: Off

; error_reporting
;   Default Value: E_ALL & ~E_NOTICE
;   Development Value: E_ALL | E_STRICT
;   Production Value: E_ALL & ~E_DEPRECATED

We can maintain the same level of error reporting that we established in development, though it is reasonable to use a less-strict level in production, such as E_WARNING. Using E_ALL might reveal production-specific bugs, but if our environments are similar, we probably would have caught these in development. It is important to periodically review the errors in the log file that we specify in the .ini, as it may get very large over time!

Additional Suggestions

If you don't have the ability to modify the php.ini file in your environment, you may be able to utilize the ini_set() function to establish some of the settings mentioned above. Otherwise, you may have to contact your provider or sysadmin to properly configure your settings.

Read More

This article is one in a several-part series on PHP security. View all the articles