Securing a go REST API - Part 4: CSRF
This is part 4 of a multipart series on how to secure your API in golang. This post will talk about dealing with Cross-Site Request Forgery (CSRF in short), an attack on web applications where the attacker tricks users into performing unintended actions. This attack only works for APIs served to a frontend (e.g. a React application), as it is based on the fact that browsers send the user’s cookies automatically when calling a web page.
Securing a go REST API - Part 3: Passwords, Tokens and Secrets
This is part 3 of a multipart series on how to secure your API in golang. This post will talk about dealing with passwords, tokens and generally secrets. We won’t go into the cryptographic details here and instead focus on the best practices because I want this to be a short and concise guide rather than another blog post about hashes and rainbow tables.
Hash your passwords This post is not going into the details of why you should hash your passwords, but you need to look for mostly two things:
Securing a go REST API - Part 2: Timeouts
This is part 2 of a multipart series on how to secure your API in golang. We covered session management in part 1.
Filippo Valsorda makes an excellent case about exposing your go service. This blogpost will only talk about one little piece of all this, namely timeouts. Timeouts are one of the rare cases where the default values aren’t secure in golang. This is mostly due to historical reasons and maintaining backwards compatibility, however the often used helper methods http.
Why I gave up on ORMs
My day job is working on backends and that usually includes lots of SQL. Many people are familiar with the idea of an ORM library that maps runtime objects to database objects. (An ORM library is much more than that, of course, but that’s not what this is going to be about)
Before coming to go, I made heavy use of ORMs in C# (namely Entity Framework). As one does, I looked for an ORM in go and found GORM, probably the most popular go ORM.