Web Server Security

Author: Kiruthiga Sinnarajah
Last Revised: April 06, 2007

Web servers are generally exposed to outsiders and as a result are vulnerable to compromises and attack. When using a web server while most users are happy simply browsing, there is a small fraction of users who attempt to knowingly exploit information and services from web servers. Improper web server security can compromise sensitive information, allow a denial-of-service attack, manipulation of information, deletion of files, placement of malicious software or cause financial grief[1]. There are several preventative measures that help make a web server more secure such as changing file permissions and being cautious when it comes to CGI scripts.

The Threat

Setting up a web server does not require as much effort as it used to several years ago. Most users think of it as a fun and quick way to share files however if a web server is not secured properly there is a risk of intrusion into personal and company computers. Running a web server on a computer opens a port on the computer allowing access from the outside world. Unless security measures such as specifying which users may access the web sever, any user will be able to connect.


CGI Scripts

The open architecture of Web servers allow arbitrary Common Gateway Interface (CGI) scripts to be executed on the serverís side of the connection in response to remote requests[1]. These CGI scripts which are used to generate the content of a web page may contain potential security holes. CGI scripts are not inherently insecure but poorly written code can open holes on what could be a well-secured system. One security threat is providing access to potentially dangerous system commands/applications[2]. For example, a hacker can Ďtake overí a service running on a server such as a mail application via an HTML form-based script and use it for their own purposes such as sending out spam or acquiring confidential user information. Also, while not a security threat, a poorly written CGI application can use up a systemís available resources to the point where it is depleted and becomes unresponsive.

Unfortunately, there is no answer to scripts, the only recommendation is to use the newest version of the script and discard the script with potential security holes. It is a good idea to validate user-supplied data before accessing files or operating system services. Authors of CGI scripts should always keep security in mind when they write the scripts.

File Permissions

Proper web server file permissions will go a long way in decreasing the level of vulnerability. This is especially key for the server root directory as this is where CGI scripts, logs and configuration files are kept. It is recommended that this directory is made writeable only by the webmaster. An alternative is the use of a username and password. While this provides add security, passwords can still be determined with the right software, guessed if the password is obvious or intercepted when it is transmitted from browser to server. Unauthorized access can allow remote users to steal confidential information, execute commands that allow modification of the host system, break into the system and launch denial-of-service attacks which have a large effect on bandwidth.


Web server software programs should also be kept in mind. As a general rule of thumb, a basic server is safer than one that offers lots of features offered by the program, the more likely it contains security holes.

Only services that are deemed absolutely necessary should be run. Examples of these are FTP and a secure login capability should be run. Any unneeded services can be exploited and become an area for attack.

Security patches and fixes should be implemented as soon as possible as these defend against common threats. In 2001, a survey of Microsoft IIS sites running SSL found that a surprising portion of sites were still vulnerable to various exploits that had already been identified and for which patches or fixes were already available.

General password considerations also apply to web server passwords. Avoid simple, easy to guess passwords. Always change default passwords to eliminate unnecessary accounts such as guest.


  1. "Web Security 2.0," Software Development Times, 166 (Jan 15 2007): 38.
  2. World Wide Web Consortium, "The World Wide Web Security FAQ", http://www.w3.org/Security/Faq/ (accessed April 01, 2007).

See Also

External Links