DEV Community: Bedirhan Elibol

One using (true) policy makes your whole table public

Bedirhan Elibol — Tue, 03 Nov 2026 09:23:15 +0000

You hit a permission error. The quick fix is a policy with using (true), and the error goes away. So does the protection on that table.

Why one loose policy wins

Postgres policies are permissive by default. When a table has several permissive policies for the same command, a row is visible if any one of them returns true. They are combined with OR.

create policy "Org members read invoices" on invoices for select
  using (org_id in (select org_id from members where user_id = auth.uid()));

create policy "allow read" on invoices for select
  using (true);

The first policy is correct. The second makes it irrelevant: every row passes true, so anyone holding the anon key can read every invoice.

Find them

select schemaname, tablename, policyname, roles, cmd, qual, with_check
from pg_policies
where qual = 'true' or with_check = 'true';

Each row is a policy that lets everything through for its command and roles. Some are on purpose, like a public countries table. The rest are bugs.

Make it a test

Run that query in CI after your migrations and fail when it returns a table that is not on an allow list. One test covers the whole class, including the policy nobody has written yet: the next one an agent adds to make an error go away.

If you need a hard limit

Restrictive policies are combined with AND. A row has to pass at least one permissive policy and every restrictive one, so a restrictive policy caps what any permissive policy can open:

create policy "org boundary" on invoices as restrictive for select
  using (org_id in (select org_id from members where user_id = auth.uid()));

With that in place, a later using (true) cannot widen reads past the org boundary.

Two more to check

with check (true) on insert or update: anyone allowed to write can write any row.
A policy with no to clause applies to every role, anon included.

Zelsis flags using (true) policies on pull requests. There is also a 14-second version of this post: https://youtube.com/shorts/hHrIz9LJhD0

Have you found one of these in a real project? I'm curious what the "temporary" reason was.

Has an accessibility bug ever cost you a user?

Bedirhan Elibol — Fri, 30 Oct 2026 13:17:06 +0000

Most accessibility bugs pass every test and look fine in a demo. The first report often comes from a customer who couldn't finish checkout, and plenty never write in at all.

The ones I keep seeing in pull requests: a div with onClick that Tab skips, an icon button a screen reader announces as just "button", and a label not tied to its input, so the field has no name.

A quick test before a release: unplug the mouse and try to finish your main flow with only the keyboard. It takes five minutes.

Has one of these ever cost you a user or a deal? And how do you catch them now: a linter, axe in CI, manual testing, or customers telling you?

Four privacy bugs that get through code review

Bedirhan Elibol — Thu, 29 Oct 2026 12:06:23 +0000

Privacy bugs rarely break a test. The page renders, the form submits, the dashboard fills up with sessions. They show up later, in a complaint or an audit, and by then the code has been in production for months.

Here are four that show up often in pull requests. Each one is small to fix.

1. A cookie banner with no way to refuse

export function CookieBanner() {
  return (
    <div className="cookie-banner">
      <p>We use cookies to improve your experience.</p>
      <button onClick={acceptAll}>Accept all</button>
      <a href="/cookies">Settings</a>
    </div>
  );
}

GDPR and the ePrivacy rules expect refusing to be as easy as accepting. Regulators in France have fined sites for a banner where Accept is one click and Reject needs a trip through a settings page.

The fix is a second button with the same weight:

<button onClick={acceptAll}>Accept all</button>
<button onClick={rejectAll}>Reject all</button>

To find this in your own code, open the banner component and search for "reject", "decline" or "necessary only". If there's an Accept button and none of those words, users have no direct way to say no.

2. The consent cookie lives too long

Cookies.set('cookie_consent', 'all', { expires: 730 }); // 2 years

The CNIL recommends keeping a consent choice for 13 months at most, then asking again. Watch the units, because each library uses a different one: js-cookie's expires is in days, Express res.cookie takes maxAge in milliseconds, and the Next.js cookies API takes maxAge in seconds. Copy maxAge: 31536000 from a Next.js file into Express and one year becomes about eight hours. The reverse mistake turns a year into centuries.

Cookies.set('cookie_consent', 'all', { expires: 365 });

3. Session replay that records form input

posthog.init(KEY, {
  session_recording: { maskAllInputs: false },
});

PostHog and Sentry Replay mask inputs by default. Someone turns masking off to debug a checkout form, the PR gets merged, and from then on the replays store addresses, phone numbers and whatever else people type. That data now sits with a third party, and your privacy policy probably doesn't list it for that purpose.

Leave masking on and unmask only the fields you really need, using the tool's per-element option.

4. Personal data in the URL

router.push(`/onboarding?email=${email}`);

Query strings end up in server logs, analytics, browser history and the Referer header sent to any third-party script on the next page. An email in the URL gets copied to all of those places.

Pass it in state or in the request body, or look it up on the server from the session:

router.push('/onboarding');

One more you have to test by hand

Loading analytics or ad scripts before the user has answered the banner. This one is hard to see in a diff because it depends on load order. Open the site in a private window, open the network tab, and check what loads before you click anything.

Catching these on the pull request

I build Zelsis, a check that runs on every pull request. The first four patterns above are flagged there as medium findings: they show up as warnings on the PR and don't fail the check. Writing plain emails or phone numbers to logs, or sending them unmasked to an error tracker, is reported as high.

Public repos scan free, and you can paste one on zelsis.com to see a result without an account.

What privacy bug have you found in your own code after it shipped?

How do you stop double charges when the user clicks Pay twice?

Bedirhan Elibol — Thu, 29 Oct 2026 09:33:37 +0000

I keep finding the same pattern in checkout code. The Pay button calls fetch('/api/checkout', { method: 'POST' }), the button stays enabled, and nothing in the handler checks whether a request is already running. On a slow connection people click twice all the time, and the second click sends a second charge.

What I do now: a pending flag with an early return, the button disabled while it's set, and an idempotency key on the Stripe call built from the order id. Webhooks get a unique constraint on the event id.

What do you do? Do you rely on the button state, the server, or both? Has anyone been bitten by a retry after a timeout where the first charge had actually gone through?

How do you catch N+1 queries before production?

Bedirhan Elibol — Tue, 27 Oct 2026 08:52:02 +0000

Our test database has ten rows, so every page feels instant. An N+1 only shows up once a table has real data, and by then the page is timing out.

Two things have worked for me: query logging in development, where the same query repeating with only the id changing gives it away, and a test that seeds 50 rows and asserts the query count matches the count with 5.

What do you use? Bullet, a DataLoader, APM traces, code review? I'm curious which of them catches the case where the loop is in a component and the query is hidden in a helper.

What's the worst deploy-time lock you've hit?

Bedirhan Elibol — Mon, 26 Oct 2026 16:33:38 +0000

I've seen a two-second migration freeze a checkout page because a plain CREATE INDEX held a lock on a table with a few million rows. Staging never showed it, because staging had a few hundred rows.

What was yours? Curious which statements bit people most: CREATE INDEX, SET NOT NULL, adding a column with a volatile default, something with foreign keys?

I wrote up the three I see most often with the safe versions, if useful: https://zelsis.com/guides/postgres-migration-locks

What a release check found in well-kept open-source apps

Bedirhan Elibol — Wed, 14 Oct 2026 18:53:11 +0000

We keep a public benchmark of open-source projects that people copy from: SaaS starters, framework example apps, a few production products and some Android apps. They are well maintained and widely forked, and most of them have nothing seriously wrong. We use them to measure false alarms, so a person reads every high-severity finding on them before we count it as real.

Some of those findings held up. None of them is exotic. They are the kind of thing that gets copied into a new project on day one and is still there when it ships, so here they are with the fix for each. We left out project names because several are not fixed upstream yet, and the snippets show the shape of each issue rather than the exact upstream code.

A fallback secret that signs real tokens

An Express example app signs its JWTs with this:

const secret = process.env.JWT_SECRET || 'superSecret';

Locally this is convenient. In production, if the variable goes missing because a deploy dropped it or someone renamed it, the app keeps running and signs tokens with a key anyone can read in the repo. Nothing errors, so nobody notices.

Fail at startup instead:

const secret = process.env.JWT_SECRET;
if (!secret) throw new Error('JWT_SECRET is not set');

A storage policy that only checks the bucket

A test migration in a database client library has a storage policy shaped like this:

create policy "avatars" on storage.objects
  for all using (bucket_id = 'avatars');

for all covers insert, update and delete, and the condition never looks at who owns the file, so any signed-in user can overwrite or delete anyone's avatar. The same project has a using (true) read policy that makes every row of a table public. In an example that may be on purpose, but example migrations are exactly what people paste into real projects.

Scope write policies to the owner:

create policy "owners update own files" on storage.objects
  for update using (bucket_id = 'avatars' and (select auth.uid()) = owner_id::uuid);

A SECURITY DEFINER function without a search path

A popular subscription starter creates a trigger function that runs with its owner's privileges and no fixed search_path:

create function public.handle_new_user() returns trigger
language plpgsql security definer as $$ ... $$;

The function then resolves table names through whatever schemas the calling session puts first. If a user can create objects in one of those schemas, they can shadow a table the function writes to and run code as the owner. Pin the path and schema-qualify the tables:

create function public.handle_new_user() returns trigger
language plpgsql security definer set search_path = '' as $$ ... $$;

The same starter pins Next.js 14.2.3. That version is affected by CVE-2025-29927, where a request header lets a caller skip middleware, including any auth check that lives there. The fix is an upgrade, plus a dependency check in CI so the next advisory shows up in a pull request.

Containers that run as root and a database on every interface

Several Dockerfiles in the set have no USER line, so the app runs as root inside the container. A compose file publishes Postgres like this:

ports:
  - "5432:5432"

That binds to all interfaces. On a laptop it hardly matters. On a VPS without a firewall in front, the database is on the internet. Use "127.0.0.1:5432:5432" unless something outside the host needs it, and give the image a non-root user:

RUN useradd --create-home app
USER app

CI actions pinned to a tag

Workflows reference third-party actions as some-org/some-action@v3. Whoever controls that repo can move the tag to different code, and the job often holds a token with write access. Pin to the full commit SHA and keep the tag in a comment, so the code that runs is the code you reviewed:

- uses: some-org/some-action@<full-commit-sha> # v3

Android: cleartext traffic, exported components and a feed parser

An open-source Android podcast app sets android:usesCleartextTraffic="true" so feeds and media can load over plain HTTP. For a podcast player that is a real trade-off, since some feeds are still HTTP only, but the flag applies to every request the app makes. A network security config can allow cleartext for the hosts that need it and keep everything else on HTTPS.

The same app exports a broadcast receiver and a widget that accept its own custom actions, so any other installed app can send them. If only the system needs to reach a component, a permission on it, or a separate unexported component for the app's internal actions, closes that.

It also parses remote feeds with a default SAXParserFactory and no DTD or external-entity settings, on XML that comes straight from the internet. Whether that is exploitable depends on the parser underneath, which is a good reason to set those features explicitly and test them on the Android versions you support.

A database upgrade step builds UPDATE ... WHERE file_url='...' by concatenating a file path into the string. A path with a quote in it breaks the query. That is a bug before it is a security issue, and a bound parameter fixes both.

A migration that locks a busy table

One migration creates an index on an existing table without CONCURRENTLY. On Postgres, a plain CREATE INDEX blocks writes to the table until the build finishes. On a small table nobody notices. On a large one, the deploy that runs it stops writes for as long as the index takes.

create index concurrently if not exists idx_orders_user on orders (user_id);

CONCURRENTLY can't run inside a transaction, so some migration tools need it in a migration of its own.

Checking your own project

None of this needs a pentest. Each issue is visible in code or config, and each fix is a few lines. The hard part is noticing before release, when nobody is reading the Dockerfile or the old migrations anymore.

We build Zelsis to run that check on every pull request, across code, dependencies, migrations, containers and CI config, in most languages. Public repos get a free scan at zelsis.com. If you maintain one of the projects above and want the details, write to contact@zelsis.com and we'll send what we found.