Pepe Fagoaga

When Row-Level Security (RLS) is enabled on a table, PostgreSQL must guarantee that any user-supplied predicate cannot see rows they shouldn’t. Concretely, the RLS-derived filter is enforced before any user-provided condition. If PostgreSQL were to apply a user’s condition first, for example: 1 2 3 4 SELECT finding.id FROM findings WHERE tenant_id = '81884830-05c9-4178-aef6-d3e2a5e70284' AND text_search @@ to_tsquery('secret'); it could inadvertently reveal whether hidden rows match that condition. To prevent this, PostgreSQL only allows user predicates to be “pushed down” into an index scan if they are marked LEAKPROOF—i.e., proven never to leak information about rows. ...

Introduction While JWT-based sessions are not the typical choice for website authentication, sometimes due to your solution’s architecture, you might find that there is no other choice. This is often the case when your frontend is unable to use traditional stateful sessions via cookies, requiring the backend to manage both authentication (AuthN) and authorization (AuthZ). In this post, we’ll dive into the unique challenges of using JWTs for session management, from handling token expiration and revocation to mitigating potential web security vulnerabilities. Along the way, we’ll explore strategies to make JWT-based sessions as secure and effective as possible. ...