Risk Breakdown · Privacy High

The compliance problems a reviewer finds after you ship.

PII in your logs. A Facebook pixel that fires before anyone clicks "accept." A user's email in a URL that gets logged by three different proxies. None of it crashes anything, so it sails through testing. Then a GDPR complaint, an App Store rejection, or a Data Safety mismatch turns a code habit into a legal one. IOnclad flags the patterns a privacy review would catch while you still have time to fix them.

What actually counts as a privacy gap

It's broader than a missing cookie banner. IOnclad's privacy overlay runs on every scan and looks for the data-handling patterns that map directly to regulation:

Why it bites at the worst time

A privacy gap is quiet. The app works, users sign up, and nobody notices until the cost lands all at once. Here's where it actually comes from.

1. PII you log forever without meaning to

A single console.log(user.email) or logger.info(\`charge for \${creditCard}\`) ships PII straight into your log aggregator, where it sits indefinitely, replicated across backups, and visible to anyone with dashboard access. Under GDPR that's processing you can't account for, and under the right to erasure you now have to find and scrub it from every log line. Error trackers are the same trap: attach a user object to a Sentry or Bugsnag report and that PII lives on a third party's servers, outside your control.

2. Tracking that fires before consent exists

Drop in a Google Analytics snippet, a Meta pixel, or a Mixpanel call with no consent check around it and you're tracking EU visitors the instant the page loads. GDPR Article 6 needs a lawful basis, and the ePrivacy Directive needs consent before non-essential tracking runs. "We'll add the banner later" means every visit until then is a violation, and the pixel in your HTML is the evidence.

3. PII smuggled into URLs and analytics

Passing ?email=\${user.email} or a user ID as a query parameter feels harmless. It isn't. URLs get logged by your server, every proxy in between, the browser history, and your analytics tool, which means that email is now sitting in a dozen systems you never meant to put it in. This is one of the easiest ways to leak personal data without a single "breach."

4. Store rejections you don't see coming

Import Apple's AdSupport framework but forget to call the App Tracking Transparency prompt, and Apple rejects the build. Request location, contacts, camera, or microphone in your Android manifest without a matching Data Safety declaration, and Google Play flags it. These aren't fines, they're a blocked launch, and you find out the day you submit instead of the week before.

The shape of a real incident

It usually starts as one convenient line during a fast week:

// debugging a payment bug, just want to see what's coming in
logger.info(\`checkout for \${user.email}, card \${creditCard}\`);

// the marketing tag added "to measure the launch"
<script>fbq('track', 'PageView');</script>   // no consent gate

// the share link that looked fine in review
const url = \`/invite?email=\${user.email}\`;

// none of this breaks the build. it just quietly
// writes PII to logs, tracks EU users without consent,
// and leaks an email into every server access log.

How to fix it

• Strip PII from logs and error context. Use structured logging with automatic redaction, and add a beforeSend hook on your error tracker to scrub user data before it leaves.
• Gate every tracker behind consent. Initialize analytics and pixels only after the user opts in. A simple consent flow or a consent management platform both work, as long as nothing fires first.
• Keep PII out of URLs. Pass it in a POST body or a header, never a query parameter. Treat any value that ends up in a URL as something that will be logged.
• Wire up the store requirements early. Call ATTrackingManager.requestTrackingAuthorization() before touching the IDFA, and fill out the Play Console Data Safety form for every permission you request.
• Add a retention story. Soft-delete columns, TTL or expiry fields, and a cleanup job give you a real answer for data minimization and right to erasure instead of "we keep everything."
• Link a privacy policy and, for California, a Do Not Sell option. Both are table stakes for GDPR, CCPA, and the app stores.