News for hackers. Stuff that matters.

A comment on Security assessment techniques for Go projects. Parent comment

Re:Security assessment techniques for Go projects by matwood on Friday November 08, 2019 @08:43AM (#21482053)
You should be, but because a lot sql in Go is still just strings it makes it easy for someone to bypass because of laziness/sloppiness/distracted/whatever when composing queries. There is also the issue that if the Go code needs to run on Postgres it has to use '$' params instead of '?'. So again, back to string concatenation to support both or use some library like squirrel[1].

[1] https://github.com/Masterminds/squirrel

[ Parent | on HN ]
Re:Security assessment techniques for Go projects by weberc2 on Friday November 08, 2019 @10:35AM (#21483109)
Is it common to write apps that target multiple databases with SQL as the abstraction point? SQL behaves so differently across vendors (with respect to performance, extensions, etc) that I would be more inclined to write distinct queries for each vendor rather than try to find strings optimal for every vendor.
[ Parent | on HN ]
Re:Security assessment techniques for Go projects by kasey_junk on Friday November 08, 2019 @03:16PM (#21486248)
It used to be much more common when we shipped software to enterprises that required particular databases.

It’s much less common in SaaS environments.

[ Parent | on HN ]