by
Joseph Mendez
3 (2 reviews)
Security Headers
Security headers are directives used by web applications to configure browser-side security defenses.
Security Headers ranks #7,548 among WordPress.org plugins with 800+ active installations, a 3/5 rating from 2 reviews, and was last updated Oct 30, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Tested up to WP 6.9.11 (Current: 7.1.4)
v1.6.2
Current Version v1.6.2
Updated 1 week ago
Last Update on 30 Oct, 2026
Refreshed 1 week ago
Last Refreshed on
Top 10% by installs
Downloads -38.7% this week
Actively maintained
Rank
#7,548
—
No change
Active Installs
800+
-5.7%
KW Avg Position
9.5
—
No change
Downloads
7.6K
+10 today
Support Resolved
0%
—
No change
Rating
60%
Review 3 out of 5
3
(2 reviews)
Next Milestone 900
800+
900+
322
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 45 more installs to reach 900+
Rank Changes
Current
#7,548
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
3.0
2 reviews
Overall
60%
5
1
(50%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
1
(50%)
Security History
Source: WPVulnerabilityNo known vulnerabilities on record for Security Headers. Checked 3 months ago.
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 1.6.2
- Last Updated
- Oct 30, 2026
- Requires WP
- 6.0+
- Tested Up To
- 6.9.11
- PHP Version
- 7.4 or higher
- Author
- Joseph Mendez
Support & Rating
- Rating
- ★ ★ ★ ☆ ☆ 3
- Reviews
- 2
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade Now
TL;DR
AI summary of the plugin's readmeSecurity Headers is for WordPress site owners and administrators who want to manage browser security headers without editing server config. It provides a settings page to configure, test, and diagnose headers like HSTS, CSP, and X-Frame-Options directly from WordPress.
- Admin settings page
- HSTS controls with preload warning
- Referrer-Policy settings
- X-Frame-Options settings
- Permissions-Policy custom value field
- Content-Security-Policy builder
- Diagnostics screen for headers
- Import, export, and reset tools
Frequently Asked Questions
Common questions about Security Headers
New installs enable a minimal enforced Content-Security-Policy: upgrade-insecure-requests on HTTPS responses. It upgrades HTTP resource URLs to HTTPS without adding script or other source restrictions. Resources unavailable over HTTPS will fail to load. You can disable it using the HTTPS resource upgrades checkbox. Existing installations keep their previous behaviour and must opt in to HTTPS resource upgrades after updating. Advanced CSP remains disabled by default because source restrictions need website-specific configuration.
Yes, for advanced CSP. Report-Only mode reports advanced policy issues without blocking resources. The separate HTTPS resource upgrades setting remains enforced even while advanced CSP is in Report-Only mode. When advanced CSP is enforced, the baseline directive is merged into that policy.
No. A grade depends on the headers actually returned for each scanned URL and the scanner's criteria. The minimal upgrade policy does not restrict script sources or provide the XSS protection of a carefully configured CSP.
Open Security Headers > Discover / Review / Enforce and acknowledge Start / Resume Discovery. On first use, this saves a settings backup and replaces advanced CSP with a same-origin Report-Only starter. This does not block advanced policy violations; the separate HTTPS upgrade baseline remains enforced if enabled. Purge page, hosting, and CDN caches. Browse important pages and exercise forms, booking, chat, lazy loading, analytics, login roles, and consent states. HTML detection suggests scripts, styles, images, fonts, frames, media, and manifests. Browser reports provide additional origins for dynamic requests, CSS dependencies, APIs, and workers. The plugin does not fetch external JS/CSS files or execute JavaScript to crawl the site. Review suggestions. Approve recognised required origins or reject unwanted suggestions. Unsafe inline/eval and broad data/blob script permissions require a separate risk acknowledgment; manually configured hashes/nonces can be preferable. Discovery never automatically includes sources in the policy. Existing manual CSP fields remain explicit configured permissions, so rejecting a suggestion does not override them. Verify the public Report-Only policy for a same-site page path. The tool does not add cache-busting parameters or follow redirects. It requires HTTP 200 HTML with the matching policy. This confirms one response, not full site coverage. Approvals and policy changes invalidate verification. With no pending suggestions, confirm browser testing and cached-page header coverage, then use Enforce Reviewed Policy. The fixed policy contains approved origins plus manual fields; it never expands based on HTML or public reports. Purge caches again and verify the enforced policy. Resume Report-Only testing before changing approvals. Use Restore Saved Settings to return to the full plugin configuration saved before the first workflow start. Normal settings saves cannot skip verification and directly enforce a changed reviewed policy. Imported settings are returned to Report-Only for retesting.
No. Detection is a compatibility aid, not a security audit. Public browser reports can be forged and are never treated as trusted approvals. The plugin may miss features not exercised, conditional requests, logged-in variations, and reports that do not arrive. Missing reports do not prove safety. Origin approvals permit more than a single file, and broad permissions in manual fields can weaken CSP. Discovery is capped at 250 source/directive pairs; reports are limited to 16 KB, 20 entries per batch, and 60 entries per client per minute. Limits can prevent complete observations. New installs use the reviewed-source workflow and disable automatic source inclusion. Existing installations keep legacy settings until an administrator explicitly starts discovery. Legacy automatic inclusion can also permit attacker-injected sources and is retained only for compatibility.
In bounded WordPress options on your own site, not in an external service unless you configure an external report endpoint. Page paths are stored without visitor query strings or fragments. Reports and source suggestions are untrusted. Removing the plugin through WordPress uninstall deletes its settings, reports, discovery, verification, and workflow backup options.
Page caches, hosting proxies, and CDNs can serve HTML without running WordPress. PHP headers cannot cover those responses. Apache rules can cover static cache files when Apache processes the plugin's generated .htaccess rules, but Nginx does not read .htaccess. Ask your host to apply security headers at the cache-serving layer and avoid duplicate headers. Purging caches alone may not solve the issue if the cache bypasses WordPress again. Auto-detected advanced CSP requires WordPress to inspect rendered HTML. It cannot detect sources in a static cache response. Emergency CSP bypass also requires a WordPress-generated response and cannot bypass policies enforced by your server or CDN.
No. HSTS should only be enabled when your site is fully available over HTTPS.