Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t we all just want to use SQL on the front end?

vjpr.medium.com

Post reply on HN
Print view View original

151–160 of 184 posts

Re: Don’t we all just want to use SQL on the front end?

#151

Post by recursivedoubts »

No.

The front end is an untrusted computing environment and anything you give to your front end developers you also give to potentially hostile users.

The security implications of things like GraphQL are, frankly, bonkers, but nobody seems to notice.

This is in stark contrast with the server side, where you do have a trusted computing environment and you can, to an extent, give your developers what amounts to "root" access to the database.

I wrote a blog post on this a while back:

https://intercoolerjs.org/2016/02/17/api-churn-vs-security.h...

Re: Don’t we all just want to use SQL on the front end?

#152

Post by neonological »

ipnon wrote: post #149
neonological wrote: post #132

Earlier quoted context omitted.

I mean the guy is front end. Front end development doesn't involve any security.

I think you would be surprised how quickly and easily an attacker can automatically export vulnerabilities in web applications with programs such as Ffuf and SQLmap.

Not disagreeing. I'm just saying people on the front end never actually deal with security, hence this is the mentality that is the instigator of the suggestion of using SQL on the front end.

Re: Don’t we all just want to use SQL on the front end?

#156

Post by smuemd »

porsager wrote: post #107
smuemd wrote: post #103

With HashQL there actually was an experimental implementation of this idea https://github.com/porsager/HashQL-todos-sample/blob/master/...

Not only experimental. I've been running HashQL in production for over a year now. I really wish I had time to write about it. I'm going to present it at https://speakeasyjs.com/ on the 7th of May, so I'll have to get something ready until then at least.

I wish I had time to try it out ;) Make sure to share that video of your presentation via the mithril channel on gitter so that I don't miss it.

Re: Don’t we all just want to use SQL on the front end?

#157

Post by tommek4077 »

Because you all stopped to use serverside rendering and let the browser do risky stuff.

If you want to cut down the overhead, use a simple PHP app and deliver prerendered HTML with JS just for the ajax calls. Its fast, reliable and tested in the wild. Servers are so powerful they can handle thousands of users at the same time.

You also don't drain the users batteries anymore, a win-win.

Re: Don’t we all just want to use SQL on the front end?

#158

Post by lelanthran »

ownagefool wrote: post #40
AaronFriel wrote: post #27

Because it exposes a lot of inner details and potential security/privacy risks if clients are able to change parameters. But... it seems like if you're willing to expose your data model to the client, then it seems like some combination of code signing the SQL (with parameters left empty) along with the acceptable list of named parameters, e.g.: Signed blob: { sql: "SELECT name, email, ... FROM users WHERE users.id =…

Not quite sure I get what's signing the request. Presumably if it's the client, it can be tampered with, so we're guessing that there's still an API layer signing things? That said, I guess you could just add row / column ACLs to the database user, and then map the database user to the app user.

> Not quite sure I get what's signing the request.

Server sends the query so server can send the signature hash with it, so the server signs the query with the server's key and sends both query and signature.

If the server ever receives a query without a signature or with a signature that is incorrect it can ignore or generate an error.

Re: Don’t we all just want to use SQL on the front end?

#159

Post by 02020202 »

i dont see why not. in the era of ddd, es, projections... one could simply prepare "public" data projection, versioned of course, and let the client build the query to pick and choose the data it needs. not necessarily the end user, but the front end can have multiple use-cases and layers to represent data. this could be easily distributed into cheap read-only dbs.
Post reply on HN