Talking about security and configuration issues, we are correct if we say the devil is in the detail. The configuration of a web server, a database server, a CMS, or an application should find the point of equilibrium between being completely usable and useful and being secure for both users and owners.

One of the most common misconfigurations in a web application is that it contains some kind of a web administration site that is accessible to all of the internet; this may not seem to be such a big issue, but if we think that an administrator login page is much more attractive to crooks that any contact us form as the former gives access to a much higher privilege level, and there are lists of known, common, and default passwords for almost every CMS, database, or site administration tool we can think of. So our first recommendations focus on not exposing these administrative sites to the world, and removing them if possible.

Also, the use of a strong password and changing those that are installed by default (even if they are strong) should be mandatory when publishing an application to the internal company's network, and should be much more strenuously enforced when publishing to the internet. Nowadays, when we expose a server to the world, the first traffic it receives is port scans, login page requests, and login attempts, even before the first user knows that the application is active.

The use of custom error pages helps the security stance because default error messages in web servers and web applications show too much information (from an attacker's point of view) about the error, the programming languages used, the stack trace, the database used, the operating systems, and so on. This information should not be exposed because it helps us understand how the application is made and gives the names and versions of the software used. With that information, an attacker can search for known vulnerabilities and craft a more efficient attack process.

Once we have a server with its resident applications and all services correctly configured, we can make a security baseline and apply it to all new servers to be configured or updated, as well as to the servers that are currently productive, with the proper planning and change management process.

This configuration baseline needs to be continually tested in order to consistently keep improving it and keep it protected from newly discovered vulnerabilities.