CEH · M13

Web server hardening: from exposure to verifiable configuration

Inventory exposed files, services and administration routes before addressing updates, permissions and browser protections. Each control needs its own verification.

After this lesson, you can
  • Distinguish server, deployment-artifact and application responsibilities.
  • Explain the purpose and limits of security headers.

Prerequisites: CIA and security controls: define what needs protection

Reduce unnecessary public exposure

A web server should deliver intended public content. Source code, backups, environment configuration and administration tools in the public directory expand exposure. Define an artifact allowlist and inspect the actual output instead of relying only on filename assumptions.

Updates and least privilege address another layer: supported software, restricted service-account file permissions and independently controlled administration interfaces. A working homepage does not establish those properties.

Further reading: NIST SP 800-115: Security Testing and Assessment

Headers guide browsers; they do not fix every weakness

Content-Security-Policy can restrict browser content sources. X-Content-Type-Options: nosniff limits MIME sniffing. frame-ancestors controls who may embed a page. Check actual responses and page behavior rather than assuming a configuration entry took effect.

Headers do not replace application authorization, input handling or parameterized database access. Restrictive settings can also block legitimate features, so verify required article, image, script and error-page behavior around deployment.

Further reading: OWASP: HTTP Headers Cheat Sheet

Example: an unintended backup in the public directory

A synthetic deployment includes index.html, app.css, photo.webp and database-backup.sql. Only the first three are on the public-content allowlist.

Security headers on the homepage do not make the backup safe to publish. Exclude it from deployment, verify it is unavailable remotely and assess follow-up based on any exposure.

Conclusion: Artifact validation and header checks are necessary but distinct.

Offline exercise: review a release manifest

Use the four fictional filenames without reading real backups or secrets.

  1. Compare each file with the public-content allowlist.
  2. Write a pre-release blocking condition and a post-release check.
  3. Add expected HTTP states for a normal page and a nonexistent page.

Expected result

Exclude the backup. Expect 200 for a normal public page and 404 for a missing page.

Check your work

How would returning the homepage with 200 for every missing path affect error identification?

Finish and clean up

Save the synthetic checklist.

Q&A · Check your reasoning

Choose an answer and confidence, then read every explanation. Answers stay in this browser.

ceh-m13-hardening-q1 · Original practice

Does CSP on the homepage make a database backup safe to publish?

Does CSP on the homepage make a database backup safe to publish?
ceh-m13-hardening-q2 · Original practice

After adding nosniff to configuration, what remains?

After adding nosniff to configuration, what remains?

Connect the next idea

Terms: Hardening·Evidence boundary

Sources & scope

These sources support the technical principles. Examples, questions and exercises are original to this series.