First, what even is Work.ink?
It's a platform where you post links and get paid when people click them. The site shows ads to your visitors and splits the revenue with you. You've probably seen links like this before.
To get paid, you have to give them your real name, your address, your bank info, and in some cases a photo of your ID. That's a lot of personal information to hand over to anyone. Keep that in mind.
They sometimes also show explicit (+18) ads to everyone, with no age verification whatsoever. But that's not even the main issue here. The main issue is much worse.
The problem, explained in simple terms
Imagine you go to a bank. You walk up to the teller and say "Hi, I'm account number 48291, give me my money." The teller just... does it. No ID. No PIN. No questions asked. Just your account number, which by the way is printed on the outside of your front door for anyone to read.
That's Work.ink's security model. Not an exaggeration.
Here's what's actually happening:
When you log in, Work.ink gives your browser a little "ID card" called a JWT token. Every time you do something on the site, check your balance or request a payout, your browser shows that card and the site goes "yep, that's you, come on in."
Inside that ID card, there's only one thing written: your user_id. A number that identifies your account. That number is the only thing protecting your money, your name, your address, and possibly your ID documents.
user_id number is publicly visible in the source code of every single Work.ink link you've ever shared. Anyone. Any random person. They copy your link, hit "view source" in their browser, and they have your number. No hacking required. Zero technical skill needed. Okay but can't they fake the ID card?
The ID card (JWT token) has a signature on it to prevent forgery. Think of it like a wax seal on an envelope. Work.ink uses something called HS256 to create that seal.
The problem with HS256 is that one single secret password is used to sign the ID cards of every single user on the platform. All of them. Yours, mine, everyone's.
If someone figures out that password, and if it's a weak one, tools exist that can crack it automatically in minutes, they can create their own fake ID card with your number on it. And the site will believe it. Completely.
What can they actually do if they get in?
Full access. Everything the site can show you, they can see too:
→ Your real name and home address
→ Your payment details
→ Your ID documents (KYC)
→ Your earnings balance (which they can try to withdraw)
This isn't "they can see your username." This is identity theft territory.
The screenshots
Here's the API responding with the JWT token after login:
Here's that token decoded. You can see it only contains user_id. That's it. That's the whole thing:
Here's the API returning full personal data, name, address, payments, just because you presented a token with the right user_id:
And here's a public Work.ink link with the user_id sitting right there in the HTML, visible to anyone on the internet:
Work.ink's Official Response , And Why It Misses Everything
Work.ink published an official response to this report: blog.work.ink , Re: Work.ink's JWTs. I want to be upfront: I'll acknowledge where they're right, and I'll be specific about where they're wrong. Because unlike their response, this one actually addresses what was reported.
Their post calls me ignorant. Twice. A platform that left an IDOR vulnerability in their login, shipped APIs with zero authentication protecting real people's names and payment data, and silently patched everything hoping nobody would notice , calling someone else ignorant takes a specific kind of confidence. Let's go through it.
Point 1: They violated Kerckhoffs's Principle without knowing it
If the key is genuinely strong, confirming it's 64 characters costs you nothing. The refusal to do so isn't caution. It's either embarrassment or ignorance , and given the rest of this report, I'll let you decide which.
We also have no way to know whether this key was generated by a cryptographically secure random number generator (CSPRNG) or whether someone just typed the first thing that came to mind. They haven't said. They won't say. That's not security. That's hoping nobody asks.
Point 2: They ignored the actual vulnerability entirely
What they never touched: the architecture. Every account on this platform, your name, address, payment info, ID documents , is protected by one shared secret that apparently never rotates and lives on a server maintained by the same team that shipped these APIs.
What happens if a developer accidentally commits it to a repo? What if it appears in a log file? What if one employee goes rogue? There is no key rotation. No per-user session tokens. No binding between a session and a device. If that secret is ever exposed , for any reason, by anyone , every single account on the platform is immediately and silently accessible.
Their post doesn't mention any of this. Not once. Because there's no good answer.
Point 3: APIs with zero protection guarding real people's data
curl command with a user_id in the URL was enough to pull account data. They put Cloudflare Turnstile on the login page and apparently decided that was enough. Turnstile is a frontend bot challenge. It does nothing to protect API endpoints called directly. Treating it as a security boundary for a system that stores KYC documents is not a misunderstanding. It's negligence.
Their official response doesn't mention the APIs at all.
Point 4: The API that gave away names for free , and the silent patch
After the initial report, a separate API was found that returned the first name of any account holder using only a public user_id. No JWT. No headers. No authentication of any kind. A plain GET request to a public URL.
Under GDPR, silently patching a personal data exposure without notifying affected users is not a fix. It's a second violation on top of the first. Their official response, which was specifically written to address this report, never mentions this endpoint. Not a single word.
Point 5: The Google comparison
Work.ink has one shared secret, no visible rotation policy, and a team that shipped unauthenticated personal data APIs and called it secure. Invoking Google as a comparison isn't a defense. It's an accidental demonstration of the gap between what security actually looks like and what work.ink is doing.
What their response actually was
They correctly explained that HS256 with a strong secret is resistant to brute-force. That's true and was never seriously contested. Everything else in the report , the IDOR design, the unauthenticated APIs, the silent patches, the single shared secret with no rotation , got exactly zero response.
They called me ignorant for pointing out vulnerabilities that they then quietly patched without telling their users. Make of that what you will.
This wasn't a security response. It was a blog post written to look like one.
What you should do
Stop using Work.ink. If you have an account, consider that your personal information may already be at risk. Do not upload ID documents. Do not connect payment methods. If you already have, be aware of what data you submitted and to whom.
No platform that collects your real identity and banking information should have an authentication system this fragile. This is not a sophisticated attack. This is the most basic security expectation, and they failed it.
Your data is worth more than a few cents per click.
No user data was accessed, stored, or exfiltrated during this research. The goal is to warn people before someone with worse intentions finds this first.