Most organizations reduce GDPR compliance to cookie banners and privacy policies. The problem starts much earlier: with the frontend architecture itself. Every external request transfers the user’s IP address to a third party. The IP address is personal data under Art. 4 No. 1 GDPR.
The Technical Problem
When a browser loads a website, HTTP requests are sent to all referenced servers. Each request automatically includes the user’s IP address, user agent, and referrer – before the user clicks anything or gives consent. A typical SaaS landing page generates 30–80 HTTP requests to 10–20 different domains on first load.
Common GDPR Pitfalls in the Frontend
Google Fonts: Embedding via Google CDN without consent = GDPR violation (LG Munich, Jan. 2022). Solution: self-hosting.
Analytics: Google Analytics transfers personal data to the US. Solution: EU-hosted analytics like Plausible Cloud or Matomo.
YouTube/Vimeo embeds: Standard embeds load tracking scripts on page load. Solution: two-click facade.
CDN-hosted libraries: Every request to cdnjs, unpkg transfers the IP to the CDN operator. Solution: npm install + local build.
Privacy by Design
Art. 25 GDPR requires “data protection by design.” In the frontend, this means architecture must be designed so personal data is never transferred to third parties in the first place.
Key Takeaways
- The IP address is personal data – every external request is GDPR-relevant.
- Cookie banners don’t solve the problem: external requests execute before any consent.
- Google Fonts, analytics, YouTube embeds, and CDN libraries are the most common compliance gaps.
- Privacy by Design (Art. 25 GDPR) requires data protection in architecture, not as a retrofit.
- Self-hosting all frontend assets is the most consistent solution – and usually more performant.
