Why check these from outside

Privacy programs tend to live in documents: records of processing, DPIAs, a cookie policy. The failures below live in page markup, change with every marketing deployment, and are easy for an outsider to find. GDPR Article 32 asks controllers to implement security measures appropriate to the risk and names "the pseudonymisation and encryption of personal data" among them. The ePrivacy Directive's Article 5(3) requires consent before storing or reading information on a visitor's device, unless it is strictly necessary for the service they asked for. Neither is legal advice you can get from a scanner, but both have technical symptoms a scanner can see.

1. Forms that send personal data unencrypted

This is the oldest problem on the list and it still turns up, usually on a legacy landing page, a regional microsite or a form embedded by a third-party tool. There are three shapes:

  • A login form (any page with a password field) served over HTTP or submitting to an http:// address. Credentials cross the network in cleartext.
  • A personal-data form served or submitted over HTTP: fields whose type, name, label or autocomplete hint indicates email, phone, postal address, date of birth, national identifiers or payment card data.
  • An HTTPS page whose form posts to http://. The padlock is showing, and the data still leaves unencrypted. This is the one people miss, because the page itself looks fine.

The fix is the same for all three: serve the page over HTTPS and make the form action an https:// URL. Pair it with HSTS so the plain-HTTP version cannot be reached by accident (see the security headers guide).

2. Mixed content

Mixed content is an HTTPS page loading sub-resources over HTTP. Current browsers handle the two kinds differently. Active (blockable) content such as scripts, stylesheets, iframes and objects can rewrite the page, so it is blocked outright; the visible symptom is usually a broken page rather than a breach. Passive (upgradable) content such as images, audio and video is automatically upgraded to HTTPS, and fails if the server cannot answer over HTTPS. Older browsers and embedded webviews may still load either kind over HTTP, where it can be observed or tampered with in transit.

A reasonable severity split follows that line: medium when active content is loaded over HTTP, low when only images or media are. The fix is to load every sub-resource over HTTPS, and a Content-Security-Policy: upgrade-insecure-requests directive can cover stragglers while you clean up.

3. Third-party scripts without integrity checks

Every script tag pointing at another domain hands that domain the ability to run code on your page, including on the pages where people type card numbers and passwords. If the provider (or the CDN serving its file) is compromised, the attacker's code runs with the same access as yours. That is the mechanism behind web skimming attacks.

Subresource Integrity (SRI) is the browser-native defense: an integrity attribute carries a hash of the file you expect, and the browser refuses to run anything else.

<script src="https://cdn.example.net/lib/4.2.1/lib.min.js"
  integrity="sha384-..." crossorigin="anonymous"></script>

SRI only works for files that do not change, such as a pinned library version. For scripts a vendor updates in place (tag managers, payment SDKs, chat widgets), the alternatives are a Content Security Policy that restricts where scripts may load from, self-hosting a pinned copy, or accepting the dependency deliberately and recording why.

PCI DSS 4.0 requirement 6.4.3

For anyone taking card payments on their own pages, this stopped being optional. PCI DSS 4.0 requirement 6.4.3 requires that all payment page scripts executed in the consumer's browser are managed: each script is authorized, its integrity is assured, and an inventory is kept with a written justification for why each is necessary. It became mandatory on 31 March 2025, alongside requirement 11.6.1 (detecting unauthorized changes to payment pages). The PCI Security Standards Council later removed 6.4.3 and 11.6.1 from SAQ A, replacing them with an eligibility criterion that the merchant's site is not susceptible to script attacks, so check which questionnaire applies to you.

An external crawl helps with the inventory half: it records every third-party script host your pages reference, which is where a 6.4.3 inventory starts. It does not, by itself, satisfy the authorization and justification half, which is a documented decision per script.

4. Tracking cookies before consent

If an analytics or advertising cookie arrives on the very first response, before the visitor has clicked anything, it was set before consent. Under the ePrivacy Directive that is generally not allowed for non-essential cookies, and the Court of Justice of the EU confirmed in Planet49 (C-673/17, 2019) that consent requires an active choice (a pre-ticked box does not count), and that the rule applies whether or not the cookie contains personal data. The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3) extend the same logic to tracking pixels, URL tracking and similar techniques, not only cookies.

The common causes are a tag hard-coded into the page template above the consent manager, a server-side integration that sets its own cookie, or a consent manager configured in "notice" mode rather than blocking mode.

How Attack Surface Scan checks these, and its limits

The page crawl reads the HTTPS homepage, the plain-HTTP homepage and up to 10 same-host links per host, prioritizing login, sign-up, contact, checkout and account pages, with a 500 KB cap per page. It raises web.login-form-http, web.pii-form-http and web.form-posts-http (high), web.mixed-content (medium or low), web.third-party-script-no-sri (low) and web.tracking-cookie-before-consent (low), and records the third-party script hosts for each scan. The cookie finding fires only when a cookie from a list of well-known analytics and advertising tags arrives in the homepage's own Set-Cookie response, and it notes whether a known consent manager was detected. Details are on Web page and privacy checks, and the findings roll up into a Privacy (GDPR) view on the Compliance page.

The limits are deliberate and worth knowing:

  • No JavaScript execution. The crawl reads markup and response headers. Many analytics cookies are set by JavaScript after the page loads, and many scripts are injected by tag managers at runtime. Neither is visible to this check. A clean result means "nothing set by the server before consent", not "no tracking before consent". Use a real browser with a fresh profile (and the developer tools' storage and network panels) for the full picture.
  • No form submissions and no logins. Forms are read from markup only; pages behind authentication are not crawled.
  • Only your verified hosts. The crawl never follows links off the host, and third-party script hosts are recorded, never fetched.
  • Not legal advice. Findings are technical evidence for a DPIA, a privacy review or an assessor. Whether a given cookie is strictly necessary is a legal question for your privacy team.

A quick manual check you can run today

  1. Open your homepage in a private window with developer tools open, before clicking the banner. List the cookies in the storage panel. Anything from an analytics or ad vendor is a pre-consent cookie.
  2. View source on your login, contact and checkout pages. Search for action="http: and for <script src="https:// tags on other domains without an integrity attribute.
  3. Load the plain http:// version of those pages. If a form renders instead of a redirect to HTTPS, fix that first.

Then put it on a schedule, because marketing deployments change these pages more often than any other part of your estate. The free CSP builder helps with the script-source half.

Frequently asked questions

Does GDPR require HTTPS on forms?

GDPR does not name HTTPS, but Article 32 requires security measures appropriate to the risk and lists encryption of personal data as one of them. A form that sends personal data over plain HTTP is very hard to defend as appropriate, so in practice HTTPS on every page that collects personal data is the baseline.

Is Subresource Integrity required by PCI DSS 4.0?

Not by name. Requirement 6.4.3 requires that each payment page script is authorized, has its integrity assured, and is inventoried with a justification. SRI is one way to assure integrity for pinned files; a Content Security Policy and other controls are alternatives for scripts that change. Which requirements apply also depends on your SAQ type.

Can a scanner prove my site sets no cookies before consent?

A scanner that does not execute JavaScript cannot. It sees cookies the server sets in its response headers, but most analytics cookies are set by scripts after the page loads. Use a browser-based audit for full coverage, and treat a server-side pre-consent cookie as a clear finding when one is reported.

Are analytics cookies allowed before consent?

Under the ePrivacy Directive, storing or reading information on a visitor's device requires consent unless it is strictly necessary for the service the visitor requested, and analytics and advertising cookies are generally not considered strictly necessary. Some national regulators allow narrow exemptions for certain audience measurement, so confirm with your privacy team for your jurisdictions.

Sources