DEV Community: Amr Abumady

Clickjacking Still Targets Approval Buttons: A Checklist for Login Teams

Amr Abumady — Sat, 24 Oct 2026 06:36:17 +0000

Somewhere on your site there is a button that says Approve. It might confirm a sign-in on a new device, let a third-party app read an account, or authorize a payment. Clickjacking makes the person press it for a reason they never meant to.

The defenses have existed for over a decade. What has changed is the target. The approval step after a login is often the most consequential click on a site, and it is the one teams most often leave unprotected.

I'm building ClientN, so I have a stake in approval flows. The checklist below applies whatever you use.

Send the frame policy as a header

In October 2013 the IETF published RFC 7034, an informational document about the X-Frame-Options header. It tells the browser whether other sites may frame your page. The attacker's page cannot change the header your server sends.

Its successor is the frame-ancestors directive from CSP. For approval pages, a narrow rule is usually right:

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

Keep X-Frame-Options alongside it for older browsers. Two details catch teams out:

The CSP3 specification says frame-ancestors is not supported in a <meta> element, so the policy must arrive as an HTTP header.
Check every response that shows the approval, not only the main route. A retry page or a self-reloading confirmation can be a separate response with its own headers.

Frame-busting JavaScript is at best a second layer. It runs inside the framed page, and the framing page controls that context.

The variant headers do not stop

In January 2025, BankInfoSecurity reported on DoubleClickjacking. According to that report, the technique uses two windows instead of a frame. A decoy window closes on the first click and reveals a sensitive page underneath, and the second click lands on that page. The researcher, Paulos Yibelo, showed proof-of-concept account takeovers on Salesforce, Slack and Shopify. The report says popular defenses such as Content Security Policy and SameSite cookies fail against it.

So a header does not cover window switching. Two things are worth testing:

A second, deliberate step that a decoy page cannot complete, such as a passkey or device PIN prompt.
A short delay before a high-risk button becomes active.

These are design choices to test, not guarantees.

Checklist

Inventory every page where one click approves something: device sign-ins, consent screens, payment confirmations, recovery-code reveals, account deletion, and login-method changes.
Send the policy on those responses, then test it. Load the page in a frame on another origin and confirm the browser refuses to render it. From a terminal: curl -sI https://your.site/approve | grep -iE 'frame-ancestors|x-frame-options'
Show what is approved: the requesting app or device, and the access it asks for.
Require a second step for anything that grants access or changes the account.
Log every approval: the app or device, the time, whether a second step completed, and which page the request came from.

Where sign-in fits

An approval is tied to an account, and the account is usually tied to a stored email address. If the approval happened on the person's own device, with a key that stays there, a site could confirm that the same person approved a request without storing who that person is. That is a design direction, not a claim that every approval works this way today.

ClientN explores that split. The security page describes how approvals work, and the docs show how to start.

Originally published on the ClientN blog.

Founding price: what the $5 first year of ClientN membership includes

Amr Abumady — Sat, 17 Oct 2026 06:32:57 +0000

I'm building ClientN, so this is a product post. It only covers what is live today.

Free sign-in stays free. You need an email address and a passkey. There is no card and no app. Each website you sign in to gets its own anonymous CN- ID, so the same person looks like a different user to each site.

Membership is optional. The founding price is $5 for your first year if you join before 2027-01-01 00:00 UTC. After that it is $40 a year, renews automatically, and you can cancel at any time. Here is what it includes today:

Private messages from the sites you have signed in to. They arrive in your ClientN inbox, and the site never sees your email address.
Blocking and reporting any sender, at any time.
Advanced recovery: recovery codes, plus an email-based waiting path if you lose access.
The Verified Human badge, if you want it. It needs one ID or passport check from any country, plus a live selfie checked on ClientN's own server. The selfie is deleted after the check. What we keep is an encrypted face pattern and one-way document codes. Websites see only a yes or no: verified unique human.

Not ready yet: phone verification and phone recovery. The pricing page lists them as coming soon, and this post does not give a date.

Payment is handled by Polar, the merchant of record. ClientN does not receive your card number, the last four digits, or a card fingerprint.

Sign-in security is also live. Every sign-in asks for a fingerprint, face, or device PIN. Same-device sign-ins are tied to the browser that started them, so a forwarded link signs nobody in. QR sign-ins show the requesting device and country, and you pick the matching number from three choices. "This wasn't me" cancels the request. Details are at https://clientn.com/security

Links:

Pricing: https://clientn.com/pricing
Free account: https://clientn.com/signup

Questions are welcome in the comments. If the answer is "not yet", I will say so.

Verified Human. Still Anonymous.

QR-code login can be phished. Here is how we closed the hole

Amr Abumady — Fri, 09 Oct 2026 09:20:13 +0000

QR-code login looks safe. You scan a code, approve on your phone, and the computer is signed in. No password typed, nothing to phish.

We run ClientN, an anonymous sign-in service, and our own QR flow had the same hole most QR logins have. This post is about what that hole was and the four changes we shipped to close it.

The attack (QR-jacking)

The attacker opens a real website that uses ClientN and starts a sign-in. The site shows a QR code and a short match code.
The attacker copies that QR code onto a page they control: a fake "scan to claim your reward" page, a fake support chat, anything.
The victim scans it. Their phone opens the real ClientN page, on the real domain, with a valid TLS certificate. They see a match code, and the fake page shows the same one, because the attacker copied it.
The victim approves. The website signs in the attacker's browser, because that is the browser that started the request.

Nothing was faked on our side. The victim approved a real request, just not one they started. Match codes don't help when the attacker can show the same code. Passkeys don't help either: the passkey proves the victim is the victim, not that the victim is sitting at the computer that asked.

There was a second, smaller problem. If you were already signed in to ClientN, approving a website was one tap on "Confirm". No fingerprint. Anyone holding your unlocked phone could approve sign-ins.

What we changed

1. A fresh passkey for every approval

Approving a website sign-in now always asks for the passkey again, and the WebAuthn challenge is tied to that one sign-in request. Having a ClientN session cookie is no longer enough to approve anything.

2. Same-device sign-in returns a one-time code bound to the browser

When the person signs in on the same device, the site redirects to ClientN and ClientN redirects back. This works much like OAuth's PKCE:

When the site creates the request, it sends a code_challenge (a SHA-256 hash of a random secret it keeps).
After approval, ClientN redirects back to the site's registered return address with a one-time code.
The site swaps the code at POST /api/v1/sessions/{id}/exchange and must send the original secret.

The secret only exists in the browser session that started the sign-in. A forwarded link, or a code caught on the way, is useless to anyone else. This is now the default flow; QR is for the "phone for a computer" case only.

3. The QR flow shows where the request came from

For the cross-device case we can't bind to the browser, so we give the person enough to notice an attack:

Sites send the visitor's IP and user agent when they create the request. The approval page shows "Chrome on Windows · Egypt", read from a local country database. No IP is sent to a third party.
If the requester's country differs from the phone's, the page shows a red warning.
Instead of just reading a match code, the person must pick the code shown on the website out of three. One wrong pick denies the request.
A "This wasn't me" button cancels the request on the spot.

None of this stops someone who ignores every warning. It does turn "tap approve" into a step where the person has to check something, and a lazy phishing page fails at the number pick.

4. Account-side signals

The account page lists recent activity with the country it came from.
We send an email when a new passkey is added and when an account signs in to a new website for the first time.
Sign-in request data (IP, user agent, country) is erased after 30 days.

What it cost the websites

Two small changes: send end_user_ip and end_user_agent when creating a session, and handle the return code with the exchange call. We had one connected site, so the timing was easy. If you are building QR login yourself, do this before you have integrations to migrate.

Our open-source starter kit has working PHP and Node versions of the full flow, with 88 tests (35 Node, 53 PHP), including "another browser cannot take over a login even if it knows the session id": github.com/clientn/clientn-session-starter.

The whole model, in plain words, is on our security page. You can try both flows on the demo site.

If you see a way around any of this, I'd like to hear it in the comments.

Hashed Emails Aren't Anonymous: Use Pairwise IDs Instead

Amr Abumady — Tue, 06 Oct 2026 06:31:23 +0000

If your sign-in flow stores sha256(lower(email)) and you call that "anonymised", it isn't. A hashed email is a stable, cross-site identifier: every service that hashes the same address gets the same string, and ad-tech "clean rooms" are built on exactly that join.

I'm building ClientN, so I've spent a lot of time on this question. Here is the short version for developers.

Why hashing doesn't help

Same input, same output. alice@example.com hashes to the same value on your site, on a retailer's site and in a data broker's table. Matching is a plain JOIN.
The input space is small. Emails are guessable. Anyone with a list of addresses can hash them and look yours up — no "reversing" needed.
Salting per site breaks the join, but you still hold the email. You collected it, so it can leak, be subpoenaed or be shared later.

What actually limits linkability: pairwise identifiers

Give each relying site a different identifier for the same person, derived so that sites cannot correlate them. In ClientN, a user signs in with a passkey (WebAuthn) and each integrated site receives its own anonymous CN- id. Site A's id for a user tells Site B nothing.

What the site gets:

a stable id for that site only — enough for accounts, sessions, rate limits and bans on your own service;
no email and no password to store, so nothing reusable to leak.

Where it fits (and where it doesn't)

It only applies on sites that integrate it — it is not a fix for "all internet privacy".
You still need your own abuse controls; a per-site id gives you a key to apply them to without collecting identity.

Try it

Live demo: https://clientn.com/demo
Node + PHP starter (MIT): https://github.com/clientn/clientn-session-starter
Docs: https://clientn.com/docs · developer dashboard: https://clientn.com/dev

Websites are free up to 1,000 logins/month until 2027-03-31. People get a free account (email + passkey) at https://clientn.com/signup.

Verified Human. Still Anonymous. — Longer write-up on our blog: https://clientn.com/blog/hashed-emails-arent-anonymous-how-your-login-becomes-an-ad-id

Passkey Sign-In for a Small Site Without Storing Emails: The 5 Server Steps

Amr Abumady — Tue, 29 Sep 2026 06:31:34 +0000

Update, 9 October 2026: the flow got safer. The default is now a same-device sign-in: your server sends a code_challenge, ClientN sends the browser back to your return_url with a one-time code, and your server exchanges it with its code_verifier (POST /api/v1/sessions/{id}/exchange), so a forwarded link signs nobody in. QR sign-ins still work and now show the person which device and country asked. Every approval needs a fresh passkey check. The starter repo and the docs are updated; the steps below describe the QR flow.

I'm building ClientN, so read this as a founder's walkthrough, not a neutral review.

Most small sites keep a users table with an email column only because the login needs one. The email then sits there for years, gets copied into backups, and turns up in breach notices. Passkeys remove the password. The question here is whether you can also stop receiving the email.

This post walks through the flow in our open-source reference integration, clientn-session-starter (Node.js + PHP, MIT, with tests). It is not an SDK. You write server code, and the repo shows one complete, tested way to do it.

What your site gets instead of an email

After the visitor confirms with a passkey on clientn.com, your server receives a clientn_id (CN-…). That id stays the same for this person on your site and is different on every other site, so two sites can't match their users by it. You never receive a password or an email address.

The five server steps

Start a session. Your server calls POST /api/v1/sessions with your API key. ClientN returns a session id, a confirm URL, a QR code and a 4-character match code.
Bind it to this browser. Store a pending login tied to the browser: a random token in an HttpOnly cookie, and only its hash in your database. The page shows the QR code and the match code (clientn.js handles the display).
The person confirms. They open the confirm URL (a link on the same device, or the QR code on a phone), check that the match code and site name are right, and confirm with their passkey.
Verify the signed callback. ClientN POSTs a signed callback to your server. Verify the signature over the exact raw bytes. Check that the callback belongs to a pending login you started. Mark it confirmed in one atomic step.
Log the right browser in. The browser holding the pending cookie polls your /clientn/status. Once the login is confirmed, consume it exactly once, create a fresh session id and set your app cookie.

If the callback is lost, the status route can ask ClientN directly (GET /api/v1/sessions/{id}) and verify that signed answer the same way. You can also call POST /api/v1/sessions/{id}/redeliver within 30 minutes.

Why the flow is shaped like this

A few choices look fussy at first, but each one blocks a real attack:

Poll your own server, not ClientN. ClientN's public status only says the person tapped Confirm. You are logged in only after your server has accepted the signed callback.
Store the browser binding as a hash. Another browser that learns the session id still can't take over the login.
Consume the login once. In the test suite, five parallel polls create exactly one session.
Treat a repeated event as a no-op. Callbacks are retried 3 times, 5 seconds apart. Return 2xx as soon as you've recorded the event, and make the same event arriving again do nothing.

Both apps are tested against the same list: cross-site start is refused, the API key never reaches the browser, tampered or oversized callbacks are rejected, expired logins are refused, and a forged recovery answer is ignored.

Running it

# Node 22.5+ (built-in node:sqlite, no dependencies)
cd node && cp .env.example .env   # add your key + secret
npm start && npm test

# PHP 8.1+ with pdo_sqlite and curl
cd php && php tests/run.php

First register your site at clientn.com/dev and verify your domain with a DNS TXT record or a /.well-known/ file. Callbacks are sent over HTTPS on port 443 to your verified domain and don't follow redirects, so test on a real staging subdomain, not localhost.

Honest limits

Keys have no scopes yet: one key and secret per site. Rotating them ends any sign-ins in progress.
The demo apps use an in-memory rate limiter. Use your real shared limiter in production.
It only helps on sites that integrate it. It won't make the rest of the web private.
Website plans are free up to 1,000 logins per month until 2027-03-31.

Try the flow yourself on the live demo, or read the docs. If you run a small site, I'd like to hear which step would block you. That's the feedback I'm collecting this month.

What Google's €403M and $463M Fines Actually Mean for Your Login Table

Amr Abumady — Tue, 22 Sep 2026 06:37:57 +0000

Google was just fined €403M by Ireland's DPC and $463M in a separate action, both tied to how location and account data was collected and retained (Irish Times, 2026-09-21; ABC News). Neither fine is about a breach — it's about retention: data a company was allowed to collect but kept, correlated, or reused longer than the stated purpose required.

For small and mid-size sites, the same liability shows up in a much smaller, more boring place: your login table. Most auth systems ask for an email up front and keep it forever, whether or not the user ever comes back. That's a data-retention liability you're taking on for zero product benefit in the first session.

The pattern we've been building around

We've been working on ClientN, a free passkey-based sign-in you can drop into a site alongside (or instead of) email/password. Two things about the shape of it are relevant to the fines above, not because ClientN is a GDPR product, but because minimizing what you store is the actual fix, not a bigger cookie banner:

Each site gets a different anonymous ID for the same person (CN-xxxxx), not a shared identifier you could correlate against other sites.
You never see or store the person's email unless they explicitly opt to share it with you.

That's it — it doesn't replace your GDPR review, but it removes an entire category of data you'd otherwise be sitting on and eventually explaining to a regulator.

Trying it

Free for sites up to 1,000 logins/month:

Starter (Node + PHP, MIT licence): https://github.com/clientn/clientn-session-starter
Docs: https://clientn.com/docs
Live demo: https://clientn.com/demo
Dashboard: https://clientn.com/dev

Curious how other devs are thinking about minimizing account-data retention post-fines like these — what's in your login table today that doesn't need to be?

What the Revolut Breach Says About Storing Identity Documents Forever

Amr Abumady — Sun, 13 Sep 2026 06:34:33 +0000

Revolut confirmed this week that it sent customer passport scans and transaction records to attackers who impersonated a government agency with a forged legal request (Reuters, Sept 12). No server was hacked. No password was cracked. A human on the compliance side looked at a request that read like it came from law enforcement, and handed over the file.

This is the failure mode that's easy to miss when we talk about "data breaches." We spend enormous engineering effort on encryption at rest, encryption in transit, access logging, and SOC 2 audits, and then the actual leak happens because someone approved a request that looked legitimate enough. The data was sitting there, complete and exportable, waiting for exactly the right piece of social engineering.

The root problem isn't the process failure. It's that the data existed to be exported at all.

Most identity verification today follows the same shape: a site asks for a passport or ID scan, stores it (or a vendor stores it on the site's behalf), and keeps it indefinitely "in case we need it again" (for compliance, for support disputes, for re-verification). Every one of those stores is a future Revolut. The attacker doesn't need a zero-day; they need one convincing forged letter and one tired employee on a Friday.

We built ClientN around a different assumption: verification and storage don't have to be the same step.

When someone verifies as a real, unique human on ClientN, the ID/passport check and the face match happen once, and the raw documents aren't retained afterward: what persists is a cryptographic attestation, not the image. Each site the person then connects to gets a different anonymous ID (a CN- handle), scoped to that site, with no shared identifier a second party could correlate across services or exfiltrate in one shot. There's no central vault of passport scans sitting behind a support ticket queue for someone to social-engineer their way into, because the vault doesn't exist after the initial check is done.

This is a trade-off, not a magic fix. A site that genuinely needs an auditable copy of your ID for its own regulatory reasons (say, a bank) still needs to hold that copy. ClientN doesn't solve that problem, and it's not trying to be a KYC vendor for regulated finance. What it solves is the far more common case: sites that ask for identity verification purely to prove "this is one real human, not a bot or a Sybil farm," and then hold onto sensitive documents they never technically needed to keep. Passkey login for session security, a one-time Sybil-resistance check, an anonymous per-site ID, and nothing left over that a forged government letter could unlock.

If you're building anything that needs "prove you're a real, unique person" without needing "collect and retain their government ID forever," the demo is at clientn.com/demo and integration docs are at clientn.com/dev. Verified Human accounts start at $1/year during the launch window: clientn.com/signup.

Verified Human. Still Anonymous.

Why websites replaced passwords with sign-in codes — and what comes after

Amr Abumady — Fri, 04 Sep 2026 09:23:24 +0000

There's a recurring question on Hacker News that keeps resurfacing: why do so many websites now email you a sign-in code instead of asking for a password? It's a fair question, and the answer says a lot about where web authentication is heading — and about a gap almost nobody is solving.

The short version: passwords were always the wrong primitive

A password is a shared secret. You know it, the site stores a hash of it, and every breach is a race between their hashing and someone's GPU. Email codes ("magic codes") sidestep the stored-secret problem: the site never keeps anything you'd mind leaking, and the proof of identity is "you can read this inbox right now." That's genuinely better than a reused password. It's also why they spread so fast — they're cheap to bolt on and they kill the top support ticket ("I forgot my password").

But a code in your inbox is still a bearer proof. Anyone who can read that inbox — a forwarded email, a hijacked mail account, a shoulder-surfed screen — can sign in as you. It moves the weak link from the password to the mailbox; it doesn't remove it.

Passkeys are the actual fix

Passkeys (WebAuthn discoverable credentials) replace the shared secret with public-key cryptography bound to your device and unlocked by your fingerprint or face. The site stores a public key; the private key never leaves your hardware. There's nothing in the database worth stealing, nothing to phish, and nothing to type. This is the endpoint the "sign-in code" trend is stumbling toward: no password, no bearer token sitting in an inbox.

If you build web apps, this is the part worth internalizing: the industry has quietly agreed that the login secret should not be something a human types or an attacker can copy. The only debate left is the packaging.

The gap nobody talks about: "who" vs. "unique human"

Here's what neither passwords nor magic codes nor even passkeys solve on their own: is this a real, unique person — without me having to collect their identity?

Most sites answer that by hoarding data. They demand your email, your phone, sometimes your ID, and they store all of it so they can de-duplicate accounts and fight bots and Sybil attacks. You end up with the worst of both worlds: the site carries a breach liability it never wanted, and you hand over identifying data to every service you touch.

That's the problem we've been building ClientN around. The idea is to split the two jobs that authentication usually fuses together:

Prove you're a unique, real human — once. We verify a person with a passkey plus a layered "Verified Human" check (an email code, a card check, and an optional ID/passport + selfie face-match done on our own servers, encrypted at rest, never shared).
Give each site a different anonymous identifier for that person. A site sees a stable CN-… id that's unique to that site and reveals nothing else. The same human logging into two sites gets two unrelated ids, so the sites can't correlate you — but neither can be fooled into thinking one person is a thousand.

The login flow itself is not an OAuth redirect that leaks your identity to a broker. The site asks ClientN for a one-time session; you confirm on clientn.com with your passkey ("Do you want to sign in to example.com?"); we send the site back a signed, per-site anonymous id. The site gets "verified, unique, human" without ever getting you.

Verified Human. Still Anonymous.

That's the whole thesis in four words. The sign-in-code trend is a symptom of an industry that knows passwords are finished but hasn't decided what "identity" should mean online. Our bet is that the right answer is less identity, cryptographically proven — not more of it, stored in more databases.

If you want to see it working, there's a live demo forum whose only login is "Sign in with ClientN": https://clientn.com/demo. If you run a site and want to add it, the integration is a single <script> tag plus one signed callback — docs at https://clientn.com/dev. And if you just want your own Verified Human account, we're in early access at a $1/year launch price: https://clientn.com/signup.

Passwords are ending. The interesting question is what we replace them with — and whether we finally stop treating "prove you're human" as an excuse to collect everything about you.

ClientN Shield: Privacy-First Authentication for the Modern Web

Amr Abumady — Thu, 19 Mar 2026 13:04:32 +0000

Update, October 2026: ClientN is now live. This early post has been updated.

Your Identity Shouldn't Be the Price of Admission

Every time you sign up for a service, you hand over your email, name, and personal data. ClientN Shield changes that.

What is ClientN Shield?

ClientN is a privacy-first sign-in service, live since September 2026. It lets people sign in to websites that support it with a passkey, without sharing personal information: each site gets a different anonymous ID.

Key features:

Zero personal data shared with websites
Anonymous authentication that actually works
Your identity stays yours
Simple integration for developers

Try Our Privacy IQ Quiz

Think you know how your data is being used? Take our Privacy IQ Quiz.

Try it

ClientN is live. Create a free account, or see how sign-in is kept safe.

What privacy challenges do you face as a developer? Let me know in the comments!