Server Misconfiguration

As we discussed in The Client-Server Conversation, it's important to distinguish between the code that is running on the server, and the response that it sends back to the client.

Many PHP developers are used to seeing server-side error messages and stack traces injected into the HTTP response, causing them to show up in their browsers automatically. In "plain PHP", this happens when PHP's display_errors directive in their PHP configuration file is set to on. Frameworks may do something similar, generating full debugging pages when something goes wrong in the developer's server-side code.

This is fine in development, and it makes the development cycle tighter by providing immediate feedback to the developer with a simple page refresh or click of a button. However in production (live server), this can lead to serious security breaches:

The lesson here is that code can contain sensitive information that we do not want to share with the end user - for example, passwords and API keys. If something goes wrong with the database connection code, it will generate a stack trace that contains the database credentials. By dumping this trace into the response, your application is risking making this information public.

Therefore we want to keep a tight rein on what makes it into the response, and this means disabling response debugging in production. UserFrosting makes this easy to do with its production environment configuration mode.

I should point out that there is a difference between developer-facing messages, and user-facing messages. User-facing messages are messages which are intended for the end user - things like "Please choose at least one owl" or "Sorry, your owlId is incorrect!" These are generally explicitly generated by your application, and can and should be sent in an HTTP response.

Developer-facing messages, on the other hand, should only be seen by developers and system administrators. These are things like the MySQL credentials error and stack trace we saw earlier. These are the types of messages we want to avoid injecting into our HTTP response.

In general, think of the HTTP response as a carefully crafted piece of content designed to be consumed in a specific way by the client - not a dump of every possible type of output that the server might generate.

Of course errors do happen in production, and we need some way to deliver debugging and error messages to our tech team. This is typically handled with logging. By default UserFrosting logs to files in production, but the Monolog logging package we use makes it easy to send error messages to email, databases, or other notification systems!