DEV Community: Lior Karaev

The Bug That Turned My Own Inbox Into a Phishing Target

Lior Karaev — Thu, 16 Jul 2026 19:40:56 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

RamenHire (ramenhire.com) is a job board for bootstrapped, profitable startups — built with Next.js and Supabase. Job seekers apply, and companies submit listings through public forms with no login required. Every submission triggers an internal notification email, built from user-supplied fields, sent straight to the team's own inbox.

Bug Fix or Performance Improvement

lib/email-templates.ts interpolated user-controlled fields — applicant name, company name, "why interested," job description, and more — directly into raw HTML email strings with zero output encoding, including values embedded inside href="..." attributes.

That meant any of the site's four public forms (apply, post-a-job, subscribe, company registration) could inject arbitrary HTML into the notification email the team reads internally — no authentication required, no rate limit standing in the way of a single crafted submission. A malicious applicant name could silently smuggle in a fake "click here to verify your login" link, styled to look like it belonged in the template, sitting right next to the real "Review in Supabase →" button. This is a stored HTML-injection vector aimed squarely at whoever opens the inbox — a real phishing risk against the team itself, not a hypothetical.

Code

Commit 3aed95d — specifically the lib/email-templates.ts hunk. Added a small escapeHtml() helper (standard &, <, >, ", ' entity escaping) and applied it to every user-supplied value across all six email template functions — both plain text content and values embedded inside href attributes, escaped before the attribute string is built, not after.

My Improvements

The fix required more than "wrap everything in a helper" — text-node context and attribute context aren't the same problem. A value escaped only for display text still allows a quote-breakout attack inside an href="..." (e.g. " onmouseover="...), so escaping has to happen before the attribute is constructed, not at final render.

Verified this at two levels. First, locally: ran the actual template functions against a real injection payload —

"><img src=x onerror=alert(1)><script>alert(2)</script><a href="https://evil.example/phish">click</a>

— plus a separate quote-based attribute-breakout string, confirming none of it survived unescaped.

Then in production, end-to-end: submitted that same payload through the live site as a real application — real Cloudflare Turnstile challenge (not scripted around), real database insert, real notification email sent to the team inbox through the exact code path this fix touches. I opened the resulting email myself and confirmed the actual outcome: the <script> tag never executed, the fake <img> never attempted to load, and the injected link rendered as inert, garbled text sitting inside obviously-escaped characters — not a working "click here" button.

One honest caveat worth including rather than glossing over: in the screenshot below, the raw evil.example URL still appears blue and clickable. That's Gmail's own auto-linkification of any bare URL it finds in plain text — completely independent of the fix, and something Gmail would do to any plain-text email mentioning a URL, malicious or not. The actual thing this fix prevents — a disguised, legitimate-looking clickable button — is gone; the substring being technically linkable inside garbled text is a cosmetic side effect of Gmail's own behavior, not a gap in the fix.

Built and directed with Claude Code under my own review and testing — including designing the verification payloads and personally confirming the production result described above.

RamenHire: Outreach, a Real Answer, and What I Still Don't Know

Lior Karaev — Wed, 15 Jul 2026 06:28:21 +0000

Two things happened this week that matter more than anything I built: I asked 13 real companies for permission, and a stranger's public feedback closed out a security thread that started three comments ago.

The security thread closes out

A reader (credited in the comments of my last post) found three real issues in RamenHire's Supabase setup over the course of a few days — an overly broad delete permission, a question about whether upload URLs were properly tied to real submissions, and, in the most recent round, a second broad delete grant I hadn't caught either. Each one got fixed and verified against the actual production environment, not just tested locally and assumed to carry over.

The full audit — including a proper security-audit-with-severity-ratings pass, an HTML-injection fix in outbound emails, and one deliberately deferred item I'm tracking rather than rushing — is public in the repo now. Prompted entirely by someone reading closely and asking good questions in a comment section. That's a better security process than I would have run on my own, for free, because I wrote honestly about what broke.

Outreach: 13 emails, 1 real response

This week's actual work: reaching out to all 13 companies whose open roles I'd curated onto RamenHire before they knew the site existed. Permission-first, not "you're already listed, come claim it" — I've written before about why I killed that model.

The honest tally so far: one response. Featurebase's founder (genuinely lovely exchange, handled by their own AI support tool, no less) asked me to take their listing down since they manage hiring through their own Notion board — and thanked me for asking first instead of just listing them. That's a real, if small, validation of the honest approach: even a "no" landed well, because it was actually their choice.

Twelve are still silent, which is the expected outcome of cold outreach in week one, not a bad sign yet.

What's coming next

Company self-service is next on the build list — specifically, a way for a company to edit or remove their own listing without emailing me directly, using the same verified-email pattern already built for registration. Directly prompted by the Featurebase exchange: watching a real company ask "please take this down" made it obvious this needs to be self-serve, not something that routes through my inbox every time.

What I actually don't know yet

Two honest, open questions, and I'd genuinely like real answers rather than assumptions:

For anyone who's looked at ramenhire.com cold — does the homepage explain what this is and why "verified bootstrapped" matters, fast enough? Or does it need to work harder before someone decides whether to keep reading?

For founders specifically — before you'd register a company profile, what would you want to see first? Proof of real traffic, other companies already listed, something else entirely? I don't have enough registered companies yet to learn this from usage, so I'm asking directly instead.

Happy to hear blunt answers on either.

RamenHire, Week 1: What Happens When Strangers Actually Read Your Code

Lior Karaev — Wed, 08 Jul 2026 07:35:32 +0000

A week ago, I launched RamenHire — a job board only for bootstrapped, profitable startups. This week was less about building new features and more about the internet doing what the internet does best: finding the gaps I didn't know I'd left.

Here's what actually happened.

The verification question that wouldn't go away

RamenHire's whole pitch rests on one promise: every listed company is genuinely bootstrapped, not VC-funded. So when someone commented on Product Hunt asking, essentially, "okay, but how do you actually verify that?" — it wasn't a gotcha, it was the single most important question anyone could ask.

The honest answer at the time was: manually, by me, checking Crunchbase and a Google search. Not glamorous, but true. Saying that out loud publicly forced me to actually think about whether that's good enough, and to start being upfront about it rather than letting "verified ✓" do more rhetorical work than it's earned.

Killing my own feature before it shipped to real users

The original plan for company profiles was: pre-populate profiles for the 13 companies whose jobs I'd already curated, then let them "claim" their profile via a magic link when I reached out.

Building it out, the framing started to bother me. These companies don't know RamenHire exists yet. Pre-building a profile for them — even a good-faith one — quietly implies a relationship that isn't there. So I scrapped the claim flow entirely and rebuilt it as pure self-registration: companies find RamenHire, register themselves, and I approve manually. Nothing gets built for anyone without them asking first.

It's slower. There's no clever growth hack of "look, you're already listed!" It also means the directory launches empty and stays empty until real companies show up on their own. But it's the version I can defend if anyone asks how it works — which, per the above, someone always eventually does.

Writing legal pages nobody will read, correctly, on the off chance someone does

Privacy Policy and Terms of Use are the least exciting part of any indie project, and the easiest to fake with a template. I didn't want to do that, partly because RamenHire has real EU visitors (GDPR isn't hypothetical), and partly because I'd rather the page be accurate than impressive.

So instead of filling in a template, I had the actual codebase audited first: what data gets collected, where it's stored, which third parties touch it, what cookies actually fire. Two findings from that audit mattered more than the policy text itself:

Google Analytics was firing unconditionally, for every visitor, with zero consent gate. Not a documentation gap — an actual compliance gap.
Admin notifications were quietly landing in a personal Gmail inbox instead of the project's real address.

Both got fixed as part of writing the policy, not just described in it. The cookie banner now genuinely blocks GA4 until you accept — verified by checking that no cookie appears at all pre-consent, not just that a banner shows up.

The comment that actually mattered

I wrote a separate post a few days back about a gnarly Supabase Storage RLS bug. A reader, Pon, left a comment pointing out that one of the example policies I'd shared — authenticated role, read access to an entire bucket — would let any signed-in user read any uploaded CV, not just their own. On RamenHire specifically, that policy is effectively admin-only today since there's no job-seeker account system, so nothing was actively exposed. But the policy itself didn't actually express "admin"; it expressed "anyone signed in," which is a landmine if that ever changes without someone remembering why.

Then, a day later, a sharper follow-up from the same person: even the write side has a gap — anonymous uploads to that bucket aren't tied to any real application, so nothing stops junk files from accumulating in storage that never came from an actual applicant. That's not a hypothetical either — it's the same category of risk as the rate-limiting and bot-protection work I'd just finished, just a door I'd left open on the Storage side instead of the API side.

That's now fixed — direct anonymous uploads have been replaced with short-lived, signed upload URLs tied to a specific application or company record, minted server-side. There's nothing left to upload to without a real submission behind it, and I verified this directly against production: a raw upload attempt using the public key now gets rejected outright.

Genuinely one of the more useful comment threads I've had on anything I've written. Public work gets public scrutiny, and this week that scrutiny made the product better twice.

Where things actually stand

Company registration is live (self-serve, admin-approved, email-verified before it even enters my review queue).
Privacy Policy and Terms of Use are up, grounded in a real data audit, not filler.
Rate limiting, real bot verification, and (as of this week) signed upload URLs are in place across every public form.
Real registered companies: 0. Real job seeker applications: 0. That's the honest number, and it's exactly why next week is about outreach, not more features.

What's next

I'm intentionally not chasing job seeker growth yet. A job board with no real employers isn't a job board; it's a list. So the next push is entirely about getting real, bootstrapped companies to actually register — cold outreach to the companies already featured, and direct conversations with hiring managers, before any push to bring in job seekers.

If you run a bootstrapped, profitable company and you're hiring, I'd genuinely love to hear from you — register a free company profile here and I'll take it from there. And if you spot something broken while looking, even better. That's basically been the whole engine of week 1.

How I Fixed Supabase Storage RLS Errors That the Dashboard UI Couldn't Solve

Lior Karaev — Mon, 06 Jul 2026 07:18:59 +0000

If you've ever spent hours staring at a 400 error on
a Supabase Storage upload despite having RLS policies
correctly configured in the dashboard — this is for you.

The Setup

I'm building RamenHire 🍜 — a job board for bootstrapped
startups. One of the features is CV upload: job seekers
drag and drop their CV directly in an apply modal, it
uploads to a private Supabase Storage bucket, and the
file path gets saved to the applications table.

Simple enough. Except it wasn't.

The Error

POST https://[project].supabase.co/storage/v1/object/cvs/...
400 (Bad Request)

Then after digging into the actual response:

{"statusCode":"403","error":"Unauthorized",
"message":"Invalid Compact JWS"}

What I Tried First (That Didn't Work)

I went straight to the Supabase dashboard and added
RLS policies via the Storage UI:

Allow anonymous uploads (INSERT, anon role)
Allow authenticated reads (SELECT, authenticated role)
Allow authenticated deletes (DELETE, authenticated role)

Looked correct. Saved. Tested. Still 400.

I checked the bucket settings — private bucket, no file
size limit, no MIME type restrictions. All fine.

I verified the Supabase client was initialized correctly
with the right environment variables. Fine.

I checked the file path format, sanitized the filename,
added contentType to the upload call. Still failing.

The Actual Problem

Here's what took me too long to figure out:

The Supabase Storage dashboard UI creates policies on
the bucket level — but RLS enforcement happens on
storage.objects, not on the bucket itself.

The UI policies weren't actually applying to the right
place. They looked correct in the dashboard but weren't
being enforced at the level Supabase actually checks
during uploads.

The Fix

Stop using the UI. Go to the SQL Editor and create
the policies directly on storage.objects:

-- Drop any existing UI-created policies first
DROP POLICY IF EXISTS "Allow anonymous uploads" ON storage.objects;
DROP POLICY IF EXISTS "Allow authenticated reads" ON storage.objects;
DROP POLICY IF EXISTS "Allow authenticated deletes" ON storage.objects;

-- Allow anonymous users to upload to the cvs bucket
CREATE POLICY "Allow anonymous uploads"
ON storage.objects
FOR INSERT
TO anon
WITH CHECK (bucket_id = 'cvs');

-- Allow authenticated users to read
CREATE POLICY "Allow authenticated reads"
ON storage.objects
FOR SELECT
TO authenticated
USING (bucket_id = 'cvs');

-- Allow authenticated users to delete
CREATE POLICY "Allow authenticated deletes"
ON storage.objects
FOR DELETE
TO authenticated
USING (bucket_id = 'cvs');

Run this in the SQL Editor. Test your upload immediately.

It worked for me on the first try after hours of
debugging the wrong thing.

Why This Happens

Supabase Storage is built on top of Postgres. The actual
files and their metadata are stored in the storage.objects
table in the storage schema. When you upload a file,
Supabase checks RLS policies on that table — not on
the bucket configuration.

The dashboard UI abstracts this away, but the abstraction
is leaky. Policies created via the UI sometimes don't
propagate correctly to storage.objects, especially for
the anon role on INSERT operations.

Going directly to SQL bypasses the abstraction entirely
and creates the policies exactly where Supabase needs them.

The Key Difference

UI-created storage policy:

Targets: bucket configuration layer
Result: sometimes works, sometimes doesn't

SQL-created policy on storage.objects:

Targets: the actual RLS table Supabase checks
Result: always works

Bonus: How To Verify Your Policies Are Actually Applied

Run this in the SQL Editor to confirm your policies
exist on the right table:

SELECT policyname, cmd, roles, qual, with_check 
FROM pg_policies 
WHERE schemaname = 'storage' 
AND tablename = 'objects';

If you see your policies here — they're real and will work.
If you only see them in the Storage UI but not here —
they're not actually enforced.

TL;DR

If Supabase Storage uploads return 400 or 403 errors
despite correct-looking RLS policies in the dashboard:

Open SQL Editor
Drop the UI-created policies
Recreate them directly on storage.objects
Test immediately

The UI is convenient but unreliable for storage RLS.
SQL is the source of truth.

Building RamenHire in public — a job board exclusively
for bootstrapped, profitable startups.

🍜 ramenhire.com

If you found this useful or hit the same issue,
drop a comment — would love to know how common
this actually is.

I launched a job board for bootstrapped startups today — here's what the first day looked like

Lior Karaev — Sat, 04 Jul 2026 19:40:44 +0000

I launched a job board for bootstrapped startups today — here's what the first day looked like

Who I am

I'm a full-stack developer who's been building side projects for a while,
but always as a hobby. This week I decided to take it seriously — shipping
real products, building in public, and documenting the journey honestly.
RamenHire is my first serious attempt.

The idea

A friend got laid off from his third "high-growth" startup in four years.
Great engineer. Terrible luck with employers chasing runway instead of revenue.

That conversation stuck with me. Because there ARE great companies out there
— Basecamp, Plausible, Transistor, Payhip — calm, profitable, founder-run
businesses that have been growing steadily for years without ever taking a
cent of VC money. Places where people actually stay for years.

But there's nowhere to find jobs at them specifically. LinkedIn and Indeed
are flooded with VC-backed startups. So I built RamenHire 🍜 — a job board
exclusively for bootstrapped, self-funded startups.

What I actually shipped today

This wasn't just a landing page day. Here's what went live:

Validation → real product: Started with a static landing page and Google
Forms. By end of day, replaced everything with internal Supabase-backed forms,
a CV upload system using Supabase Storage, and a proper Post a Job page at /post-job.

CV upload with Supabase Storage: Users can now drag and drop their CV
directly in the apply modal. Files go to a private Supabase Storage bucket —
no public URLs, admin-only access. Took longer than expected because of RLS
policy gotchas (more on that below).

Admin email notifications with Resend: Every new job post request,
application, and subscriber now triggers an instant email to me with all
the details. No more manually checking Supabase tables. Resend was incredibly
easy to set up — had it working in under an hour.

Local Docker development environment: Set up Supabase CLI with Docker
for local development. Production DB stays untouched until changes are stable
and explicitly pushed. Should have done this from day one.

Analytics and SEO: Google Analytics 4, Google Search Console, sitemap,
robots.txt, Open Graph tags, and JobPosting schema markup for rich results.

What I actually learned today

Supabase RLS with Storage is not the same as RLS on tables.
I spent an embarrassing amount of time getting a 400 error on CV uploads.
The policies were correctly set in the UI but uploads kept failing. Turns out
Storage RLS policies need to target storage.objects directly via SQL —
the UI policies weren't applying correctly. Once I ran the SQL directly
in the editor, it worked immediately.

Validate the idea before writing a single line of real code.
I launched a static landing page first — no backend, no auth, just a headline
and two Google Form links. Only after seeing real signups from 6 different
countries did I invest in building the real product. This saved me weeks of
building something nobody wanted.

DNS propagation is always slower than you expect 😅
Spent way too long staring at "Pending" status on Resend's domain verification.
It eventually resolved itself. Lesson: set it up and go do something else.

Claude Code is a genuine force multiplier.
100% of this was built with Claude Code. Not vibe coding — I reviewed every
decision, understood every line, and caught several issues before they hit
production. But the speed difference is real. What would have taken me a week
of evenings took one focused day.

What's next

Admin dashboard — approve/reject job posts without logging into Supabase
Move hardcoded job listings to database-driven
Stripe integration once validated
Blog section for SEO content

The honest numbers

33 users in the first few days from 6 countries (US, Germany, Israel, Canada, UK, South Korea)
0 paying customers
0 real job listings yet — still hardcoded
Built in roughly one week of evenings and one full day

I'd love to hear from you

Would you use a job board specifically for bootstrapped companies?
If you run a bootstrapped startup and are hiring — would you post there?
What would make this more useful for you?

All job posts are free during early access.

🍜 Visit RamenHire