Skip to main content

CCPA Compliance Implementation: All tag requests are made over HTTPS

A guide on how to audit your tag security with ObservePoint. Ensure all tracking requests use HTTPS to meet CCPA "reasonable security" standards and prevent the leakage of personal information.

Written by Luiza Gircoveanu

Overview

This is a straightforward, fully automatable check: it scans every outbound tag request for a plain http:// scheme rather than https://, since a tag firing over an unencrypted connection exposes any personal information in its payload to any passive network observer between the browser and the vendor's server.

Note: This guide is provided for informational purposes only and does not constitute legal advice. Consult qualified legal counsel regarding your organization's specific CCPA/CPRA compliance obligations.

Why it is important

Beyond CCPA's "reasonable security" requirement, an HTTP tag request is a trivially exploitable weakness on public or untrusted networks and also triggers browser mixed-content warnings and blocking behavior, which independently degrades page functionality and analytics data quality. This finding tends to have both a compliance and a technical-quality dimension.

Implementation

  1. Run a full-site Audit.

  2. Check the pre-built ObservePoint report for Tag Requests Not Made Over HTTPS.

  3. Any request in the report above is unambiguously a defect — update the tag's endpoint to https:// with no further triage needed.

Remediation

For remediation, check the next steps:

  • Update the tag's configured endpoint URL in the tag manager or vendor snippet to use https:// rather than http://. Most vendors support HTTPS endpoints, and this is typically a one-line configuration change rather than a code-level fix.

  • For legacy or unmaintained vendor scripts that don't support HTTPS at all, this is a signal to evaluate whether the vendor relationship should continue, since a vendor unable to support basic transport security is a broader risk beyond this single check.

  • Re-run the Tags report after the fix and confirm the flagged request no longer appears with the http:// scheme.

Conclusion

This is the easiest fix in the entire framework: there is essentially no legitimate reason for a production tag request to use plain HTTP, so treat any finding here as an immediate, same-day remediation rather than something to batch into a larger release.

Related Articles
Did this answer your question?