E-commerce Privacy Risks: Cookies and Online Payments

E-commerce Privacy Risks: Cookies and Online Payments – CIPT Guide

Overview
E-commerce runs on personal data: browsing behaviour, device identifiers, delivery addresses, purchase histories and, above all, payment credentials. For the IAPP Certified Information Privacy Technologist (CIPT) exam, this topic sits within Privacy Risk Management and the technologies that create privacy threats online.

You are expected to understand:
• how cookies and similar tracking technologies work;
• what risks they create;
• how online payments are processed and secured;
• which legal and industry frameworks apply;
• which technical and organisational controls a privacy technologist should recommend.

Why It Is Important
• Scale of data collection: A single web page can load dozens of first-party and third-party scripts. Each one can set cookies, read identifiers or send data to advertisers, analytics providers and data brokers.
• Regulatory exposure: The rules come from several sources:
– the EU ePrivacy Directive (Article 5(3), the cookie rule);
– the GDPR;
– the UK PECR;
– the CCPA/CPRA in California (sale and sharing of data, opt-out rights, Global Privacy Control);
– the FTC Act Section 5 (unfair or deceptive practices);
– COPPA (children);
– PSD2 (Strong Customer Authentication in the EEA).
Regulators such as the CNIL have issued fines in the hundreds of millions of euros for cookie consent failures.
• Financial harm: Payment data breaches lead directly to fraud and identity theft. They also bring card brand penalties under PCI DSS, class actions and loss of customer trust.
• Privacy by design: Technologists build the consent management platforms, tag governance, tokenization and encryption that turn policy into practice. The CIPT exam tests exactly this bridge between law and engineering.

What It Is: Cookies and Tracking Technologies
A cookie is a small text file. A web server sends it to the browser, and the browser stores it and returns it with later requests to that domain. Because HTTP is stateless, cookies let a site remember users. They are classified in several ways:

By lifespan
• Session cookies: stored in memory and deleted when the browser closes. Typically used for shopping carts and login sessions.
• Persistent cookies: have an expiry date and survive across sessions. Used for remembering preferences or tracking over time.

By origin
• First-party cookies: set by the domain the user is visiting.
• Third-party cookies: set by a different domain whose content is embedded in the page (ad networks, social widgets, analytics). These enable cross-site tracking and profiling, the core privacy concern. Browsers such as Safari (ITP) and Firefox (ETP) block them by default, and Chrome has moved toward restricting them.

By purpose (the key distinction for consent law)
• Strictly necessary: needed to deliver a service the user explicitly requested, such as a shopping cart, authentication, load balancing or security. These are generally exempt from consent under the ePrivacy Directive.
• Preference/functionality: language or region settings.
• Analytics/performance: measuring site usage. These usually require consent in the EU. Some regulators, such as the CNIL, allow narrow exemptions for strictly configured audience measurement.
• Targeting/advertising: behavioural advertising and retargeting. These always require prior consent in the EU and are a 'sale' or 'sharing' trigger under the CPRA.

Security attributes
• Secure: the cookie is sent only over HTTPS.
• HttpOnly: page scripts cannot read the cookie, which mitigates XSS theft.
• SameSite (Strict/Lax/None): limits cross-site sending, which mitigates CSRF and tracking.
• Domain/Path scoping and short expiry: limit exposure.

Similar technologies (treated like cookies by regulators)
• Web beacons/pixels: 1x1 invisible images or tags that report page views or email opens.
• Local storage and IndexedDB: browser storage that is larger than cookies.
• Flash LSOs ('Flash cookies'): historically used for respawning ('zombie cookies').
• Browser/device fingerprinting: identifying a device from fonts, screen size, user agent, canvas rendering and similar attributes. No storage is involved, so users cannot delete it, and it is highly privacy-invasive.
• ETags and cache-based tracking.
• SDKs and mobile advertising IDs (IDFA/AAID): the in-app equivalent of cookies.
• Server-side tagging and CNAME cloaking: disguising third-party trackers as first-party.

Privacy Risks from Cookies and Tracking
• Covert surveillance and profiling: cross-site tracking builds detailed profiles, which may reveal sensitive inferences such as health, sexuality or finances.
• Lack of transparency and valid consent: pre-ticked boxes, cookie walls, 'by continuing to browse you agree' banners and dark patterns (for example, a large 'Accept' button with a hidden 'Reject').
• Third-party data leakage: pixels on checkout or health pages can send personal data to platforms. Examples include Meta Pixel cases and FTC actions such as GoodRx and BetterHelp.
• Re-identification: pseudonymous identifiers can be linked to real identities through logins, emails or data brokers. Under the GDPR, cookie IDs are personal data (Recital 30).
• Security risks: session hijacking, XSS cookie theft, CSRF and Magecart-style skimming scripts injected into checkout pages.
• Over-retention: cookies with multi-year expiry and unlimited server-side logs.
• Children's data: behavioural tracking of under-13s violates COPPA without verifiable parental consent.

How It Works: Cookie Consent and Governance
1. Discover: scan the site for all cookies, tags, pixels and SDKs, and keep a tag inventory.
2. Classify: sort each item into the necessary, preference, analytics or marketing categories. Record the owner, purpose, duration and recipients.
3. Notify: publish a clear cookie notice or policy listing purposes, third parties and lifespans.
4. Obtain consent: use a Consent Management Platform (CMP). The EU standard for consent is GDPR Article 4(11) and Planet49 (CJEU 2019):
– freely given, specific, informed and unambiguous;
– given by an affirmative act;
– no pre-ticked boxes;
– reject as easy as accept;
– obtained before non-essential cookies fire.
5. Enforce technically: block non-essential tags until consent (prior blocking). Integrate with tag managers and Google Consent Mode, and honour IAB TCF signals where used.
6. Respect opt-out signals: in the US, offer opt-out via a 'Do Not Sell or Share My Personal Information' link and honour the Global Privacy Control (GPC) signal, as required in California.
7. Allow withdrawal: provide a persistent preference centre.
8. Record and audit: keep consent logs as evidence of accountability. Re-scan regularly, since sites change constantly.

Opt-in vs opt-out: the EU/UK model is opt-in (prior consent). The US model is generally opt-out (notice plus a right to refuse sale/sharing), except for sensitive data and children.

What It Is: Online Payments
An online card payment involves several parties:
• the cardholder;
• the merchant (the e-commerce site);
• the payment gateway/processor;
• the acquirer (merchant's bank);
• the card network (Visa, Mastercard and others);
• the issuer (cardholder's bank).

Data in scope includes:
• the Primary Account Number (PAN), cardholder name, expiry date and service code (together, cardholder data);
• Sensitive Authentication Data (SAD): CVV2/CVC2, full track data and PINs.

Payment Privacy and Security Risks
• Data breaches of stored card data.
• Web skimming (Magecart) and malicious third-party JavaScript on checkout pages.
• Man-in-the-middle interception without TLS.
• Card-not-present fraud and account takeover.
• Excessive collection and retention of transaction histories.
• Secondary use of purchase data for profiling, or sharing it with marketers.
• Insider misuse and weak access control.
• Insecure third-party processors.

How It Works: Payment Controls
• PCI DSS (Payment Card Industry Data Security Standard): an industry contractual standard set by the PCI Security Standards Council and enforced through card brands and acquirers. It is not a law. Version 4.0 is current. Its 12 requirements are grouped under six goals:
– build and maintain a secure network;
– protect account data;
– maintain a vulnerability management program;
– implement strong access control;
– monitor and test networks;
– maintain an information security policy.
Key rules:
– SAD such as CVV must never be stored after authorisation;
– the PAN must be rendered unreadable when stored (encryption, truncation, hashing or tokenization);
– display masking shows at most the first 6 and last 4 digits;
– v4.0 adds requirements to inventory and authorise payment-page scripts (6.4.3) and detect tampering (11.6.1), a direct response to Magecart.
• Scope reduction: the best privacy-by-design approach is to keep card data off merchant systems entirely. Options include hosted payment pages, iframes or redirects to a PCI-compliant processor (SAQ A eligibility), and third-party wallets such as PayPal, Apple Pay and Google Pay.
• Tokenization: the PAN is replaced with a random token that has no mathematical relationship to the original. The real PAN sits in a secure vault, so stolen tokens are useless. This is ideal for stored cards and recurring billing. Network tokens and device tokens in mobile wallets add domain restrictions.
• Encryption: TLS 1.2+ in transit, strong encryption at rest, and point-to-point encryption (P2PE). Encryption is reversible with the key, so key management is critical. Tokenization differs: the token alone cannot be decrypted.
• Strong Customer Authentication (PSD2 SCA) and 3-D Secure 2: multi-factor authentication using two of three factors (knowledge, possession, inherence) for EEA electronic payments. Risk-based exemptions apply.
• Data minimisation and retention: collect only what is needed for fulfilment and legal obligations, such as tax and anti-fraud. Delete or anonymise after retention periods. Do not reuse transaction data for marketing without a lawful basis or consent.
• Vendor management: conduct due diligence on processors, obtain their PCI Attestation of Compliance (AOC), and put Data Processing Agreements in place (GDPR Art. 28).
• Other laws:
– GLBA for financial institutions;
– state breach notification laws, which almost all cover card numbers combined with security codes;
– GDPR Art. 32 (security) and Arts. 33–34 (breach notification within 72 hours to the authority).

Connecting Cookies and Payments
The highest-risk point in e-commerce is the checkout page. It combines identity, address, payment data and many third-party scripts. Good practice includes:
• removing marketing pixels and non-essential tags from checkout and confirmation pages;
• using Content Security Policy (CSP) and Subresource Integrity (SRI);
• marking session cookies Secure, HttpOnly and SameSite;
• ensuring confirmation URLs and pixels do not leak order details or emails in query strings.

Exam Tips: Answering Questions on E-commerce Privacy Risks: Cookies and Online Payments

1. Know the classifications cold.
• Session vs persistent describes lifespan.
• First-party vs third-party describes who sets the cookie.
• Necessary vs non-essential describes purpose, which decides consent.
Questions often swap these terms to trick you. Third-party persistent cookies are the classic tracking vector.

2. Strictly necessary equals no consent needed (EU).
• Shopping cart, login and security cookies are exempt.
• Analytics and advertising cookies are not exempt.
• If a question asks which cookie can be set without consent, pick the one essential to the service the user explicitly requested.

3. Valid consent means prior, affirmative and granular.
• Eliminate any answer involving pre-ticked boxes, implied consent from scrolling, bundled consent or cookie walls (in most EU interpretations).
• Eliminate any answer that fires trackers before the banner is answered.
• Remember Planet49.

4. Distinguish jurisdictions.
• EU/UK cookies fall under the ePrivacy Directive/PECR, with GDPR standards for consent.
• US approaches are notice and opt-out (CPRA 'Do Not Sell or Share', GPC) plus FTC deception enforcement for broken promises.
• Read the scenario's location carefully.

5. Fingerprinting is not a loophole.
Regulators treat it like cookies because it accesses or derives information from the device. It is harder for users to control, so it is considered more privacy-invasive.

6. PCI DSS is a contractual industry standard, not a law.
This is a frequent exam trap. Also remember:
• CVV/SAD can never be stored after authorisation, even if encrypted;
• the PAN may be stored if protected.

7. Tokenization vs encryption.
• Tokenization replaces data with a non-mathematically-related surrogate and reduces PCI scope.
• Encryption is reversible with a key.
• When asked for the best way to reduce risk of storing cards for recurring payments, tokenization is usually the answer.

8. Prefer scope elimination.
When asked for the best or most effective control, choose the answer that avoids collecting or storing the data at all. Examples are a hosted payment page or third-party processor. Compensating controls on data you didn't need come second. This reflects data minimisation and privacy by design.

9. Spot the checkout pixel scenario.
If a scenario describes analytics or ad tags on a payment or order-confirmation page, the risk is leakage of personal and transactional data to third parties and Magecart-type skimming. Good answers include:
• removing the tags;
• script inventory and authorisation;
• CSP/SRI.

10. Cookie security attributes.
• HttpOnly protects against XSS reading cookies.
• Secure enforces HTTPS.
• SameSite reduces CSRF and cross-site leakage.
Map each attribute to the threat it addresses.

11. Think lifecycle and accountability.
Strong answers mention:
• inventory or scanning;
• documented purposes;
• retention limits;
• consent records;
• vendor contracts (DPAs, AOCs);
• periodic audits.
Watch for answers that are a one-off fix ('add a banner') versus an ongoing program. The program is usually better.

12. Read qualifiers carefully.
Words like FIRST, BEST, MOST likely and PRIMARY matter.
• The first step in cookie compliance is usually discovering or auditing what cookies exist.
• The primary risk of third-party cookies is cross-site tracking or profiling.
• The best payment control is often minimising or outsourcing card data handling.

13. Eliminate distractors.
Answers that rely solely on the privacy policy, user responsibility (for example, 'users can delete cookies') or security through obscurity are rarely correct. Look for technical enforcement aligned with user choice.

Quick Recap
• Cookies enable state but also tracking. Third-party, persistent and fingerprinting techniques create profiling risk.
• In the EU, non-essential cookies need prior informed consent. In the US, provide notice and opt-out and honour GPC.
• Enforce consent technically through a CMP and tag governance, and keep consent records.
• Payments: never store SAD, protect the PAN, follow PCI DSS, apply SCA/3-DS in the EEA, and reduce scope with hosted pages and tokenization.
• Lock down the checkout page: no unnecessary third-party scripts, secure cookies, CSP and SRI.
• Always favour minimisation, privacy by design and accountable, continuous governance.