Configure Apache Security Headers on Ubuntu VPS: Complete Guide

Understanding Apache Security Headers for VPS Protection

Apache security headers shield your site from clickjacking, cross-site scripting, and man-in-the-middle attacks. These HTTP response headers tell browsers exactly how to handle your content securely.

Shared hosting customers rarely get access to these settings. With Hostperl VPS hosting, you control the entire security stack. You can protect both your sites and visitors with enterprise-grade policies.

This guide covers installing and configuring essential headers on Apache with Ubuntu 22.04 or 24.04. You'll implement Content Security Policy, HTTP Strict Transport Security, and other critical headers that pass security audits.

Prerequisites and Initial Apache Setup

First, confirm your Apache installation includes the headers module. Most Ubuntu setups include this by default:

sudo apache2ctl -M | grep headers

No "headers_module" in the output? Enable it:

sudo a2enmod headers
sudo systemctl restart apache2

Check your configuration structure:

ls -la /etc/apache2/sites-available/

You can modify individual virtual host files or create global settings. Virtual host configuration gives you better granular control for most hosting scenarios.

How to Configure Apache Security Headers with Content Security Policy

Content Security Policy (CSP) stops cross-site scripting by controlling which resources browsers can load. Start basic, then refine based on your site's needs.

Edit your virtual host file:

sudo nano /etc/apache2/sites-available/your-domain.conf

Add these CSP headers inside your VirtualHost block:

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; object-src 'none'; child-src 'self'; form-action 'self'; base-uri 'self';"
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; object-src 'none'; child-src 'self'; form-action 'self'; base-uri 'self'; report-uri /csp-report"

The Report-Only header tests policies without breaking functionality. Watch your error logs to spot legitimate resources that need whitelisting.

Configuring HSTS and Transport Security

HTTP Strict Transport Security forces browsers to use HTTPS exclusively. This blocks protocol downgrade attacks and cookie hijacking.

Add HSTS to your SSL-enabled virtual host:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

The max-age sets policy duration to one year. The includeSubDomains directive applies HSTS to all subdomains. Only use preload if you plan to submit your domain to the HSTS preload list.

For staging or gradual rollouts, start shorter:

Header always set Strict-Transport-Security "max-age=300; includeSubDomains"

This gives you five minutes to test before the policy sticks in browsers.

Setting Up Clickjacking Protection Headers

X-Frame-Options prevents your pages from loading in frames, blocking clickjacking attacks. Pick your approach based on embedding needs:

# Completely deny framing
Header always set X-Frame-Options "DENY"

# Or allow same-origin framing only
Header always set X-Frame-Options "SAMEORIGIN"

# Or specify allowed origins
Header always set X-Frame-Options "ALLOW-FROM https://trusted-domain.com"

For modern browsers, also use the frame-ancestors CSP directive:

Header always set Content-Security-Policy "frame-ancestors 'self' https://trusted-domain.com;"

CSP frame-ancestors overrides X-Frame-Options in supporting browsers. Keep both for compatibility.

Additional Security Headers Configuration

These additional headers round out your security posture. Add them to your virtual host:

# Prevent MIME type sniffing
Header always set X-Content-Type-Options "nosniff"

# Enable XSS filtering
Header always set X-XSS-Protection "1; mode=block"

# Control referrer information
Header always set Referrer-Policy "strict-origin-when-cross-origin"

# Disable unnecessary features
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=()"

# Remove server version information
ServerTokens Prod
Header always unset Server

Permissions-Policy replaces the older Feature-Policy header. Customize the directive list for your application's actual requirements.

Testing and Validating Security Headers

After implementing headers, test everything thoroughly. Restart Apache first:

sudo apache2ctl configtest
sudo systemctl restart apache2

Use curl to verify headers appear correctly:

curl -I https://your-domain.com

Check for your security headers in the response. For comprehensive testing, use online analyzers like securityheaders.com or Mozilla Observatory.

Monitor Apache error logs for CSP violations during testing:

sudo tail -f /var/log/apache2/error.log

CSP violations show up as blocked resource attempts. Adjust policies to accommodate legitimate resources while keeping security tight.

Environment-Specific Header Configurations

Different sites need tailored security headers. WordPress sites typically need these CSP adjustments:

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: *.wp.com *.wordpress.com; font-src 'self' fonts.googleapis.com fonts.gstatic.com;"

E-commerce sites using payment processors need third-party domains whitelisted:

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' js.stripe.com checkout.paypal.com; connect-src 'self' api.stripe.com; frame-src 'self' js.stripe.com checkout.paypal.com;"

Development environments often need relaxed policies. Create separate configurations for staging and production.

Troubleshooting Common Security Header Issues

Mixed content warnings often surface after implementing HSTS. Find HTTP resources loaded on HTTPS pages:

grep -r "http://" /var/www/html/ --exclude-dir=logs

Update hardcoded HTTP URLs to HTTPS or use protocol-relative URLs (//example.com/resource.js).

CSP violations breaking functionality need careful policy tweaks. Use browser developer tools to identify blocked resources, then whitelist legitimate sources.

To disable headers temporarily for testing:

# Comment out or remove header directives
# Header always set Content-Security-Policy "..."
sudo systemctl restart apache2

For sites using CDNs or third-party integrations, document your security requirements. Share CSP policies with developers to prevent integration headaches.

Monitoring and Maintaining Security Headers

Security headers need ongoing maintenance as your site evolves. Set up regular audits with automated tools:

#!/bin/bash
# Create a simple header check script
curl -s -I https://your-domain.com | grep -E "(Content-Security-Policy|Strict-Transport-Security|X-Frame-Options)" || echo "Headers missing!"

Schedule this weekly via cron:

0 9 * * 1 /home/user/check-headers.sh

Log CSP violations to a dedicated endpoint for analysis. Create a simple PHP script to collect violation reports:

Review violation logs monthly to identify legitimate resources that need whitelisting or spot potential security threats.

Frequently Asked Questions

Do security headers slow down website performance?

Security headers add minimal overhead—typically less than 1KB per request. The performance impact is negligible compared to the security benefits they provide.

Can I use security headers with shared hosting?

Most shared hosting providers don't allow header configuration. You need VPS or dedicated hosting for full control over Apache security headers.

What happens if I set HSTS incorrectly?

Incorrect HSTS configuration can make your site inaccessible via HTTP. Start with short max-age values and test thoroughly before implementing long-term policies.

Should I enable all security headers at once?

Implement headers gradually, starting with basic protections like X-Frame-Options and X-Content-Type-Options. Add CSP and HSTS after testing to avoid breaking existing functionality.

How often should I review my security header configuration?

Review your security headers quarterly or whenever you add new third-party integrations. Monitor CSP violation logs monthly to catch configuration drift.