Dev.to Security 🔐 Cybersecurity 👁 0 📖 2 min read

Three privacy bugs a code review rarely catches (and how to find them before release)

A visitor opens your landing page, sees a banner, and wants to say no. If the only button says "Accept all", you have a consent problem that no unit test will ever flag. Here are three of these that show up in real code,

A visitor opens your landing page, sees a banner, and wants to say no. If the only button says "Accept all", you have a consent problem that no unit test will ever flag. Here are three of these that show up in real code, with the fix for each.

1. A banner with accept and no refuse

This is the common version:

export function CookieBanner() {
  return (
    <div role="dialog">
      <p>We use cookies to improve your experience.</p>
      <button onClick={acceptAll}>Accept all</button>
    </div>
  );
}

Regulators in the EU look at whether refusing is as easy as accepting. One button for yes and a settings link buried three clicks deep for no does not pass that bar. The fix is a second button with the same size and contrast, and one click:

<button onClick={acceptAll}>Accept all</button>
<button onClick={rejectNonEssential}>Necessary only</button>

Make sure rejectNonEssential really does not load analytics or ad scripts. A reject button that still fires the tag is worse than no button.

2. A consent cookie that outlives the consent

Consent is not permanent. Guidance in the EU points to asking again after about a year. Watch for this:

res.cookie('consent', 'all', { maxAge: 5 * 365 * 24 * 3600 * 1000 });

Five years means a visitor who clicked "accept" once in 2026 is still treated as consenting in 2031. Cap it at 12 months and show the banner again after that.

3. An embed that sets cookies before anyone clicks anything

<iframe src="https://www.youtube.com/embed/abc123"></iframe>

The standard YouTube embed loads Google scripts and sets cookies when the page loads, before the visitor plays the video. Two ways out: use https://www.youtube-nocookie.com/embed/abc123, which waits until the video is played, or render a placeholder image and only insert the iframe after a click.

How to check this on every pull request

You can grep for these by hand, and for a one-off audit that works. Over time it slips, because the banner gets rewritten and the embed gets copied from a blog post. I run Zelsis on pull requests for this. It flags a banner component with an accept control and no reject wording, a consent cookie lifetime above a year, and a youtube.com/embed iframe. These are flagged as warnings, they do not fail the check, because whether a page needs consent depends on the product and the country. The embed check only looks at JavaScript and HTML-like files.

Which of the three have you found in your own code? And does anyone have a banner pattern that makes refusing easy without hurting opt-in rates too much?

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.