WAS Information Protection Guide: Removing Sample Files and Configuring Response Headers

The type, version, and server operating system information of a WAS (Web Application Server) provides attackers with an environment that makes it easier to identify vulnerabilities and launch attacks, so it should be protected at the same level as personal information. If operated with default settings as-is, such information can be inadvertently exposed, potentially leading to financial and psychological damage.

Removing Unnecessary Files

Sample programs, manuals, and admin pages that are not needed for actual operation become attack surfaces, so they must be deleted.

• IIS: Delete directories such as iissamples, iishelp, msadc\sample in versions 5.0/6.0 (not applicable in 7.0 and above)
• Apache: Delete manual directories such as [Apache Dir]/htdocs/manual when installed via compilation
• Tomcat: Delete the webapps/examples, host-manager, manager, docs directories
• NGINX: Does not provide separate sample files or help directories

Hiding HTTP Response Header Information

To prevent the Server field in HTTP response headers from exposing WAS version and OS information, change the settings for each server.

• IIS: Install the URL Rewrite module and replace the Server header value with 0 or similar via outbound rules
• Apache: Apply ServerTokens Prod, ServerSignature Off settings
• Tomcat: Change the server attribute value in server.xml to Unknown Server or similar
• NGINX: Apply the server_tokens off; directive
• Node.js: Add the app.disable('x-powered-by'); code to remove the X-Powered-By header

Customizing Status Code Pages

Since default HTTP status code pages (404, 500, etc.) may contain server information, map them to custom HTML pages suited to each server to hide the information and provide user-friendly guidance.

• IIS: Specify custom page paths for each status code using the <httpErrors> tag in web.config
• Apache: Set file paths for each status code via the ErrorDocument directive
• Tomcat: Map status codes and locations using the <error-page> tag in web.xml
• NGINX: Specify common or individual pages for 4xx, 5xx status codes using the error_page directive
• Spring Boot: Place HTML files for each status code in the src/main/resources/error folder
• Node.js: Respond with custom error pages using res.sendFile via Express middleware