Security Protection ​

Enable CSP:upgrade-insecure-requests ​

Enable CSP:upgrade-insecure-requests to ensure all resources are loaded over encrypted connections, reducing man-in-the-middle attack risks. This also avoids errors when HTTPS pages reference HTTP resources.

Related documentation: CSP: upgrade-insecure-requests - HTTP | MDN

Enable Domain Whitelist Access Only ​

Many bloggers' sites have been cloned by malicious mirror sites. These malicious clones replace original site links, diverting site traffic and affecting SEO.
Therefore, I developed the Domain Whitelist Access Only feature to address this issue.

Enter your complete site URL in the input box above to generate the Base64 encoded result.
After enabling Domain Whitelist Access Only, enter the Base64 encoded result in "Domain Whitelist List" and "Base64 Encoded Target URL" to defend against malicious cloning.

Add SRI Validation for External Resources ​

Subresource Integrity (SRI) ensures that static assets loaded from third-party CDNs have not been tampered with, mitigating NPM supply-chain poisoning attacks via public CDNs. By adding the integrity attribute to script or link tags and pairing it with crossorigin, the browser can verify the asset hash.

All JavaScript and CSS assets in this theme already include SRI validation metadata.

SRI example:

<!-- JavaScript -->
<script src="https://example.com/lib.min.js" integrity="sha384-BASE64_HASH_HERE" crossorigin></script>

<!-- CSS -->
<link rel="stylesheet" href="https://example.com/style.min.css" integrity="sha384-BASE64_HASH_HERE" crossorigin />

You can generate SRI metadata using online tools (for example, srihash.org).

Verify Theme Package Integrity ​

Every stable release and nightly prerelease generates GitHub Artifact Attestations for all .zip artifacts, allowing anyone to confirm that a downloaded file was built by this repository's GitHub Actions pipeline and has not been tampered with in transit.

The release pipeline follows GitHub's recommended reusable-workflow pattern, where build, artifact upload, and attestation issuance all happen inside the reusable build workflow. This corresponds to GitHub's SLSA v1 Build Level 3 path.

Verification: GitHub Attestation ​

Requires GitHub CLI.

For stricter verification aligned with GitHub's recommended SLSA v1 Build Level 3 path, specify the reusable signing workflow reusable-build-theme.yml:

gh attestation verify howiehz-higan-en.zip \
  --repo HowieHz/halo-theme-higan-hz \
  --signer-workflow HowieHz/halo-theme-higan-hz/.github/workflows/reusable-build-theme.yml

gh attestation verify howiehz-higan-en.zip `
  --repo HowieHz/halo-theme-higan-hz `
  --signer-workflow HowieHz/halo-theme-higan-hz/.github/workflows/reusable-build-theme.yml

gh attestation verify howiehz-higan-en.zip ^
  --repo HowieHz/halo-theme-higan-hz ^
  --signer-workflow HowieHz/halo-theme-higan-hz/.github/workflows/reusable-build-theme.yml

A successful verification confirms the file is intact and its origin is trusted. If you also specify --signer-workflow, it confirms that the artifact was signed by the expected reusable build workflow.