CCPA Compliance Implementation: No mixed-content or insecure resource loads on pages that collect personal information

Overview

This check reviews browser console output on form-bearing pages specifically for mixed-content warnings (an HTTP image, script, or stylesheet loaded on an otherwise HTTPS page) which undermine the end-to-end security of any page collecting personal information, even when the form submission itself is properly secured.

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

Forms that collect personal information must be served and submitted over HTTPS end-to-end, and a mixed-content resource on that page undermines the page's overall integrity under California's "reasonable security" standard, since it introduces an unencrypted resource-load pathway alongside the otherwise-secure form, even if the actual form submission is unaffected.

Implementation

Identify form-bearing pages using the same classification as the Notice at Collection check, then run a Web Audit against that subset.
Check the pre-built ObservePoint report for Pages with Tag requests not made over HTTPS, filtering or cross-referencing its results down to your form-bearing page list. This OP-managed template report already catches any tag/resource request whose URL doesn't contain https, which covers the mixed-content half of this check without building a custom report.
To verify the submission itself: build a Journey that fills in and submits the form with a representative test value, then attach a Rule at the submission step checking the outbound request URL on that step for anything not over https. Read the result with get_journey_run_rule_results, and use analyze_journey_requests on the same run to see the actual outbound request if it fails. This is a manual workaround until ObservePoint ships dedicated form-input reporting; once that's released, this step should be replaced with the native report.

Remediation

For each flagged mixed-content resource, identify the specific asset (image, script, stylesheet, iframe) and update its reference to use https:// or a protocol-relative URL, following the same remediation pattern as the plain-HTTP-tag-request check above.
Where the insecure resource is loaded from a third-party vendor that doesn't support HTTPS, evaluate whether the resource can be self-hosted over HTTPS or whether the vendor relationship should be reconsidered given the same reasoning applied to insecure tag vendors.
Re-run the Browser Console report after remediation and confirm the mixed-content warning no longer appears on the affected page.

Conclusion

Mixed content and plain-HTTP tag requests are closely related findings with the same root cause and the same fix pattern. Reviewing them together during remediation is efficient, but keep the audit scope distinct since this check specifically prioritizes personal-information-collecting pages.