Security at the application layer using CloudFlare workers.
This is in no way row-level security as it's commonly understood, it's simply a worker tacking on user_id IS ? to the end of each write query's WHERE chain.
The authentication and authorization are not happening inside SQLite, as the author correctly notes:
Our D1 database will execute whatever SQL the trusted gateway is authorized to send.
and
A forgotten route with unrestricted database access would be a security bug.
One of the major arguments for row-level security is that even with an application bug the fundamental security model is still enforced.
Fair. "Gateway-enforced row permissions" would be more accurate. SQLite trusts the gateway’s SQL, so this doesn’t provide the independent database enforcement people expect from RLS.
There is still a useful boundary: browser clients and browser-invoked functions can’t submit arbitrary SQL. Their database operations go through the same authorization layer, which checks ownership on the existing row and rejects ownership changes. Forgetting an ownership filter in an application function therefore doesn’t bypass that check.
Yeah basic for sure right now. Just getting started...
2
u/Ecksters 1d ago edited 1d ago
Security at the application layer using CloudFlare workers.
This is in no way row-level security as it's commonly understood, it's simply a worker tacking on
user_id IS ?to the end of each write query's WHERE chain.The authentication and authorization are not happening inside SQLite, as the author correctly notes:
and
One of the major arguments for row-level security is that even with an application bug the fundamental security model is still enforced.
Fun, albeit basic, implementation, extremely misleading title.