AiutoComputerHelp HTTP Header Audit

Description

AiutoComputerHelp HTTP Header Audit checks HTTP response headers returned by the current WordPress site and highlights security controls that deserve review.

The plugin is intentionally read-only. It does not modify WordPress, .htaccess, Apache, Nginx, CDN, reverse proxy, browser policies, or server configuration.

Version 0.3.1 keeps the validated 0.3-series audit behavior unchanged and updates the plugin name, slug, and translation domain for WordPress.org review. The existing checks cover: HTTPS, HTTP-to-HTTPS redirection, redirect-chain integrity, HSTS, Content-Security-Policy, CSP Report-Only, clickjacking protection, X-Content-Type-Options, Content-Type and charset, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP, cross-origin isolation prerequisites, basic CORS exposure, Cache-Control, cookie attributes, information disclosure headers, selected obsolete security headers, and obvious conflicting singleton policies.

CSP analysis looks beyond presence or absence. It reviews high-signal conditions such as unsafe-eval, unsafe-inline without a nonce or hash, wildcard script sources, object-src, base-uri, and frame-ancestors.

The audit uses four result states: Pass, Review, Warning, and Info. A missing header is not automatically a vulnerability, and a present header does not prove that a site is secure. Some policies are application-specific deployment choices. The plugin intentionally does not calculate a numeric security score.

For safety, the audit accepts only URLs on the current WordPress site’s host and follows redirects only while they remain on that host.

Cookie auditing checks objective Set-Cookie attribute relationships and prefix requirements without exposing cookie values. The absence of Secure, HttpOnly, or SameSite is not automatically treated as a vulnerability because the correct choice depends on the cookie’s purpose.

Active origin-reflection probing, preflight simulation, deep CORS authorization testing, Clear-Site-Data, scheduled monitoring, and configuration suggestions remain outside the scope of this plugin. Basic CORS analysis validates response-header syntax and a few objective incompatibilities without assuming that public wildcard access or a specific allowed origin is inherently unsafe.

Screenshots

Installation

  1. Upload the plugin folder to /wp-content/plugins/ or install the ZIP from the WordPress Plugins screen.
  2. Activate the plugin.
  3. Open Tools > AiutoComputerHelp HTTP Header Audit.
  4. Run the audit against the site’s public URL or another URL on the same host.

FAQ

Does this plugin change my security headers?

No. The plugin is read-only.

Is a Warning or Review result proof that my site is vulnerable?

No. The report identifies configurations that deserve review. Security headers are only one layer of web security, and several policies are application-specific.

Why is missing HSTS shown as Review instead of an automatic failure?

HSTS provides valuable downgrade protection, but enabling it is a deployment decision with compatibility implications. The plugin reports the absence and evaluates the policy when present without assuming that every site must use the same deployment strategy.

Does a present CSP automatically pass?

No. The plugin also checks several high-signal CSP weaknesses and missing hardening directives. CSP is complex, so this remains an audit aid rather than a formal CSP validator.

Can I scan another website?

No. The target is deliberately restricted to the current WordPress site’s host to reduce SSRF risk and keep the plugin focused on self-auditing.

Does the plugin send data to an external service?

No. The scan is performed by the WordPress server against its own site URL. No analytics or external API is used.

Reviews

There are no reviews for this plugin.

Contributors & Developers

“AiutoComputerHelp HTTP Header Audit” is open source software. The following people have contributed to this plugin.

Contributors

Changelog

0.3.1

  • Rename the plugin to AiutoComputerHelp HTTP Header Audit and align the requested WordPress.org slug and text domain.
  • Keep the validated read-only same-host audit behavior unchanged.

0.3.0

  • First stable release of the validated 0.3 series.
  • Preserve the read-only same-host request boundary and the validated header, cookie, cross-origin, CORS, and redirect-chain audit behavior.
  • Finalize WordPress.org release metadata and the translation template without changing audit classifications or request behavior.

0.3.0-beta1

  • Promote the validated 0.3.0-alpha6 baseline to beta without changing audit classifications or request behavior.
  • Keep the read-only same-host request boundary and all validated header, cookie, cross-origin, CORS, and redirect-chain checks unchanged.
  • Synchronize plugin, readme, and translation-template version metadata for beta testing.

0.3.0-alpha6

  • Preserve all alpha5 redirect classifications and request-boundary behavior.
  • Guarantee a non-empty assessment for every Redirect-chain Integrity result, including completed chains with four or more redirects.
  • Add regression coverage that verifies redirect assessments are always populated.

0.3.0-alpha5

  • Add Redirect-chain Integrity without changing the existing header, cookie, cross-origin policy, or CORS classifications.
  • Detect HTTPS-to-HTTP downgrade redirects, loops, unsupported redirect schemes, missing Location targets, and excessive redirect chains.
  • Review cross-host redirect targets without following them, preserving the plugin’s same-site SSRF boundary.
  • Keep direct responses informational and short, coherent same-host chains as Pass.
  • Increase only the hard redirect trace ceiling for pathological same-site chains so long-chain diagnostics can be reported safely.

0.3.0-alpha4

  • Add a conservative Basic CORS Exposure check without altering the existing alpha3 controls.
  • Validate Access-Control-Allow-Origin as a single origin, *, or null and review the special null origin case.
  • Validate the case-sensitive Access-Control-Allow-Credentials: true value and flag wildcard-origin plus credentials as incompatible for credentialed CORS.
  • Validate Access-Control-Allow-Methods and Access-Control-Allow-Headers token lists and review wildcard use with credentials.
  • Report Vary: Origin context for explicit origins without treating its absence as an automatic error for fixed single-origin policies.
  • Keep valid public wildcard CORS informational because public non-credentialed resources may intentionally use it.

0.3.0-alpha3

  • Add read-only checks for Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP), and Cross-Origin-Resource-Policy (CORP).
  • Recognize current COOP tokens including noopener-allow-popups.
  • Validate COEP require-corp, credentialless, unsafe-none, and an optional report-to parameter.
  • Add a conservative cross-origin isolation summary based on COOP, COEP, and Permissions-Policy cross-origin-isolated.
  • Keep missing cross-origin policies informational because these controls are application-specific and can affect popup or cross-origin resource behavior.

0.3.0-alpha2

  • Refine cookie prefix diagnostics: distinguish a missing Secure attribute from a non-HTTPS origin.
  • Treat localhost, 127.0.0.1, and ::1 as local development contexts for the origin-scheme diagnostic only. Secure remains mandatory for __Secure-, __Host-, __Http-, and __Host-Http- style prefixes.

0.3.0-alpha1

  • Add a read-only Cookie Security Audit without changing the 0.2.3 header-analysis logic.
  • Never expose cookie values in the report; only cookie names and selected attributes are shown.
  • Warn on SameSite=None without Secure and Partitioned without Secure.
  • Validate __Secure-, __Host-, __Http-, and __Host-Http- prefix requirements conservatively.
  • Review repeated security-relevant cookie attributes.
  • Keep generic absence of Secure, HttpOnly, or SameSite informational because cookie purpose is application-specific.

0.2.3

  • Validate Cache-Control directive syntax and standard directive values instead of treating header presence alone as sufficient.
  • Warn on malformed standard directives such as non-numeric max-age and s-maxage values.
  • Review extension-only policies and request-oriented directives observed in responses without treating unknown extensions as invalid syntax.
  • Preserve conservative context-dependent handling for otherwise valid cache policies.

0.2.2

  • Validate Permissions-Policy directive and allowlist syntax instead of treating header presence alone as a pass.
  • Recognize empty, self, quoted-origin, and wildcard allowlists conservatively.
  • Warn when no valid directive is present, review mixed valid/malformed directives, and review wildcard policies.

0.2.1

  • Validate Referrer-Policy values instead of treating header presence alone as a pass.
  • Recognize all standard Referrer-Policy tokens and comma-separated fallback lists.
  • Evaluate the last recognized policy token as the effective policy.
  • Warn when no recognized policy is present and review mixed recognized/unrecognized policy lists.

0.2.0

  • Added Pass, Review, Warning, and Info result states.
  • Added priority labels without introducing a numeric security score.
  • Added HTTP-to-HTTPS redirect checking.
  • Added Content-Type and charset review.
  • Added conservative Cache-Control analysis.
  • Expanded CSP analysis for script sources, unsafe-eval, unsafe-inline, wildcards, object-src, base-uri, and Report-Only.
  • Improved HSTS analysis, including staged max-age handling and preload prerequisite review.
  • Added legacy header checks for X-XSS-Protection, HPKP, and Expect-CT.
  • Added information disclosure review for Server and X-Powered-By.
  • Added basic consistency checks for selected singleton security policies.
  • Deferred COOP, CORP, COEP, detailed CORS, and cookie auditing to later versions.

0.1.0

  • Initial experimental release.
  • Read-only same-site HTTP security header audit.