
Go programming language secure coding practices guide - rbanffy
https://github.com/Checkmarx/Go-SCP
======
tptacek
Taking some random samplings of the content, this appears to be mostly
rehashed OWASP Wiki content with some random, incomplete Go snippets. The
password hashing content is particularly bad (unsurprising, since OWASP's
password hashing content is bad). The sections are inconsistent (for instance:
the crypto section recommends "AES", demonstrates [without explaining] AES-
GCM, and the data protection section recommends Nacl). Very little of it
addresses any kind of pitfall of programming in Go. There are places where the
authors seem confused about basic Go data types (for instance, between slices
and maps).

I assume this is just a starting point, and I get that bootstrapping a book
from OWASP content is a legitimate way to create a starting point; I'd just
say: this is definitely an early starting point.

~~~
stcredzero
One thing that I've noticed in the Golang community, is that there is some
disturbingly large number of programmers there who think it's _a very good
idea_ not to use prepared statements and instead to use Input Escaping.

[https://www.reddit.com/r/golang/comments/62513u/golang_persi...](https://www.reddit.com/r/golang/comments/62513u/golang_persistence_i_want_the_security_of/dfkeljt/)

The justification? Better performance. Didn't the PHP community go through the
exact same thing years ago? (With people finally giving up and going back to
prepared statements for safety against SQL injection.)

It's so widespread that there are multiple libraries that tout this as a
_feature_!

~~~
floatboth
OMG. How would escaping be faster than prepared statements if prepared
statements are literally cached in the database server instead of re-parsing
and re-planning every time?! o_0

~~~
mohaine
To be fair, it can be faster if the binds cause the plan to be much more
efficient. I've had to remove binds before for this very reason.

Note that this was exactly once in 20 years.

------
aeijdenberg
Glad to see any doc published that gets developers thinking more about
security...

One "trend", or rather bad habit that I've noticed a lot in discussion with
other developers recently, and this doc also falls into, is that there seems
to more focus on "input sanitisation" rather than "output escaping".

Regardless of what's been done to input, if the result is that you have a
string that you need to embed into another string, then you need to know how
to escape that appropriately for the context in which it's being used. Whether
the data is user generated, or taken from your database, always assume that
it's trying to break your app, and always escape it on output.

------
philip1209
Direct link to web book: [https://checkmarx.gitbooks.io/go-
scp/content/](https://checkmarx.gitbooks.io/go-scp/content/)

------
SomeHacker44
"Don't use Go." FTFY. (Use a language that makes entire classes of security
problems impossible, such as memory-safe languages with nothing akin to a
"null pointer".)

