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.
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.
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!
I have not noticed this reviewing code for clients, and would be equally disturbed --- anyone suggesting that prepared statements should be avoided in favor of escaping is perpetuating a dangerous falsehood.
The link you posted to support your claim demonstrates exactly the contrary: the person supporting that argument has been downvoted to oblivion until they saw fit to delete their account.
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
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.
"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".)
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.