Privacy Risks Beyond Cookies: Forms, Scripts, and Third-Party Embeds

Introduction

The cookie banner is the most visible privacy compliance surface on a website. It is also the most narrowly scoped. A site can have a perfectly designed banner — equal Accept and Reject buttons, granular categories, no pre-ticked boxes — and still leak personal data to a dozen third parties the user never consented to.

This article walks through the seven categories of website privacy risk that sit beyond the cookie banner: third-party scripts, analytics defaults, form fields, embedded content, web fonts, session replay tools, and the disclosure gap between what your site does and what your privacy policy says. Most of them are absent from standard cookie banner reviews. All of them appear regularly in regulatory enforcement under both the GDPR and India's Digital Personal Data Protection Act.

The Third-Party Script Inventory You Don't Know You Have

Modern websites load remarkable amounts of third-party code. A typical SaaS marketing site pulls scripts from analytics platforms, customer support widgets, conversion tracking pixels, A/B testing tools, error monitoring services, marketing automation tags, CDN providers, advertising pixels (often dormant for months after a campaign ends), social media SDKs, embedded videos, payment processors, chat tools and authentication providers.

Each of these is a data transfer to a third party. Each requires disclosure under GDPR Articles 13/14 or DPDP Act Section 5. Each may require consent under ePrivacy Article 5(3) or the DPDP consent rules in Section 6. And every one of them is invisible in the source code of the HTML page itself — they live inside Google Tag Manager containers, inside marketing tools your team added years ago, inside frameworks that load child scripts the developer never saw.

The first risk is not that any one script is problematic. The first risk is that no one inside the company knows the complete list.

Analytics Defaults That Quietly Overshare

Standard analytics implementations collect far more than most teams realise. GA4 default settings include cross-device tracking, demographic inference, conversion attribution, advertising data, IP-based geolocation, and integration with Google Signals — which links analytics events to authenticated Google accounts when available.

Most of these are enabled by default. Most of them require additional disclosure beyond a generic 'we use Google Analytics' line in the privacy policy. Some — Google Signals in particular — require explicit consent for advertising purposes that the standard cookie banner may not cover.

The same pattern applies to other analytics platforms. Mixpanel's default identification stitches anonymous and identified events together. Hotjar's defaults include session recording, which captures form interactions and mouse movement. Amplitude's default routing sends data to US infrastructure. None of these are problems in themselves; they become problems when the deployment exceeds what the user consented to and what the privacy policy disclosed.

Forms: The Data Collection Surface Nobody Audits

Forms are the most direct personal data collection on a website. They are also the least audited surface because teams treat them as a UI concern rather than a privacy concern. The typical issues:

• Form fields collecting personal data without a clear purpose statement.
• Hidden fields auto-populated with referrer URLs, UTM parameters and click IDs — all of which become personal data when combined with the submitted information.
• Form submission events sent to third-party analytics in parallel with the primary submission target.
• Conversion tracking pixels (Facebook, LinkedIn, Google Ads) firing on form-submit, transmitting the conversion event and often the submitted field values.
• Auto-saved drafts written to localStorage that persist after the user closes the tab — including data the user typed and then chose not to submit.
• Email or phone number fields with no retention policy disclosed.
• Newsletter subscription checkbox pre-ticked, capturing marketing consent the user did not actively give.

Each of these falls under the GDPR's requirement for freely given, specific, informed and unambiguous consent — or the DPDP Act's equivalent active-consent requirement under Section 6.

Embedded Content That Sets Cookies Before the Page Renders

Embeds — YouTube videos, Vimeo players, Google Maps, Twitter posts, Instagram posts, SoundCloud clips — typically set tracking cookies the moment the embed loads, which is the moment the page renders. The user has neither consented to the embed nor interacted with it.

YouTube provides a 'no cookies' embed mode (the youtube-nocookie.com domain), but most teams use the default embed. Google Maps embeds set Google account tracking cookies on page load. A Twitter embed loads Twitter's tracking SDK before the user has scrolled to the embed.

The fix is well known: privacy-respecting alternatives (the YouTube no-cookie domain, lite-youtube-embed library, static map images instead of interactive maps) or load-on-click placeholders that defer the embed until the user explicitly requests it. The fix is almost never implemented unless someone has specifically audited the embed surface.

Web Fonts: The Most Famous Overlooked Risk

In January 2022, a Munich regional court ruled that a German website's use of Google Fonts — served from Google's CDN — violated the GDPR because it transmitted the visitor's IP address to Google without consent and without a legitimate transfer mechanism. The court awarded the plaintiff €100.

The ruling triggered a flood of follow-on complaints across Germany — many of them coordinated by noyb.eu — and a broader reassessment of any third-party-hosted asset that fetches resources from outside the EEA. Google Fonts is the famous case; the same logic applies to fonts loaded from any non-EU CDN, JavaScript libraries pulled from jsDelivr or unpkg, and avatars served from external image hosts.

The remediation is straightforward: self-host the fonts and the libraries, or use an EU-based CDN. The risk awareness is what is missing in most teams.

Session Replay and User Behaviour Tools

Session replay tools — Hotjar, FullStory, Microsoft Clarity, LogRocket and others — record granular user interactions: mouse movement, form input (including text typed but not submitted), scroll depth, click paths, page transitions. Some can capture screen content directly.

These tools are particularly sensitive under both the GDPR and the DPDP Act because they collect detailed personal data and often process it through US-based infrastructure. The standard defaults capture form fields by default, including any field the user typed into and then abandoned. Default masking of sensitive fields (passwords, credit cards) is usually applied; default masking of free-text fields, email inputs and personal notes is usually not.

Most session replay deployments require explicit, granular consent and a detailed disclosure of what is recorded, for how long, and who has access. Few have it.

The Disclosure Gap: When Your Privacy Policy Lies by Omission

The cumulative effect of all the above is the most common compliance gap of all: the privacy policy describes a tidy, minimal data flow that has nothing to do with what the website actually does.

The policy says 'we use cookies for analytics.' The website loads twelve third-party trackers, six advertising pixels, three session replay tools and one A/B testing platform. The policy says 'we may share data with our service providers.' It does not name any of them. The policy says 'we may transfer data internationally.' It does not specify which jurisdictions or which transfer mechanism applies.

Regulators are explicit on this point. GDPR Article 13(1)(e) requires naming the recipients or categories of recipients. India's DPDP Act Section 5(1)(b) requires similar specificity in the notice to data principals. A privacy policy that does not match what the website actually does is, in regulatory terms, an inaccurate disclosure — and an inaccurate disclosure is itself a violation, separate from whatever underlying processing it concealed.

The Universal Test: Would a Regulator Recognise Your Site?

A useful diagnostic: imagine a regulator opens your website in a clean browser, opens DevTools, looks at the Network tab, and then opens your privacy policy. Can they reconcile the two?

For most sites the answer is no. The Network tab shows thirty hostnames; the policy mentions two. The cookies inventory shows forty-five entries; the cookie declaration lists twelve. The forms collect six categories of personal data; the policy describes three. The site loads embeds from four jurisdictions; the policy discusses transfers in the abstract.

The gap between what the site does and what the policy describes IS the compliance risk. Everything else flows from it.

How to Audit What's Actually Running

A manual audit covers six surfaces:

1. 1Open the site in a clean browser (no extensions, no cached cookies). Open DevTools → Network. List every third-party hostname that loads on a typical page view.
2. 2Use the Application tab to enumerate every cookie set, including the path, domain, expiry, and which script set it.
3. 3Open every form on the site and inspect the submit handler. Note every endpoint the form submits to, including invisible parallel submissions to analytics or conversion tracking.
4. 4For each embedded video, map, or social embed, identify what cookies it sets on load and whether a privacy-respecting alternative exists.
5. 5For each web font and CDN-hosted asset, identify the host and check whether self-hosting is feasible.
6. 6For each session replay or behaviour tool, identify what is captured by default and whether explicit consent and policy disclosure cover it.

This is roughly a half-day audit for a typical SaaS marketing site, longer for content-heavy or commerce sites. The output is a complete inventory of what the site actually does, against which the privacy policy can be reconciled.

How a Privacy Scanner Helps

Manual audits are accurate but rarely happen because they are time-consuming, require deep technical knowledge, and need to be repeated after every release that touches the marketing or product surface.

This is where tools like ArgusEdge (for GDPR and ePrivacy compliance) and DPDPnow (for India's Digital Personal Data Protection Act) help. An external scan automates the inventory: it loads the site in a clean browser, captures every script, cookie, form endpoint, embed and asset, classifies each against the applicable regulation, and produces a list of findings mapped to the specific articles they relate to.

The scan also reads the privacy policy and compares its disclosures against what was actually observed — making the disclosure gap visible as a concrete list rather than a theoretical concern. Each finding includes the specific element that triggered it, the article it falls under, and a remediation step.

Neither tool blocks scripts, sets cookies, or generates consent banners. That is the role of a Consent Management Platform. The scanner identifies what is non-compliant; the CMP and the engineering team apply the fix.

Final Thoughts

The cookie banner is the most visible privacy surface on a website. It is rarely the most consequential. The risks that drive enforcement actions, customer complaints and procurement deal losses are the seven categories above — invisible to a casual review, well documented in regulatory case law, and almost universally underestimated.

The pattern that recurs in every category is the same: a default that overshares, a script that loaded without explicit purpose, an embed that set cookies before consent, a form that submits to a third party the policy never mentioned. Each one is small in isolation. Each one is a documented violation under the GDPR or the DPDP Act.

Running an external audit — manually if you have time, with a tool if you do not — is the single highest-leverage compliance action a website can take today. The findings are usually surprising. The remediations are usually straightforward. The cost of waiting until a regulator or customer surfaces the issue is significantly higher.