> Well, what about converting strings to business data structures safely? What about complex JSON parsing, serialization
Those are solved problems in Go's standard library. And let's be fair: while some frameworks do a lot of stuff, the majority is very bare bones and just automate serialization, so compare with the average. And some even cause even more problems than they solve (Rails mass-assignment).
> CSRF
Available in several routers, if you choose to use a custom one, or in the form of middleware if necessary.
> preventing injections
Which kind? For SQL, database/sql provides the tools necessary for avoiding SQLi, and requires the same care/discipline you'd need on a big-framework app. For XSS just use the builtin facilities of html/template rather than reinventing the wheel.
> session cookies
Library, if it's not in the router of your choosing.
> authN/authZ
Once again, let's be fair. AuthN didn't exist on Rails for 20 years, for example (and is still quite bare bones compared to libraries). AuthZ still doesn't. In Spring and .NET both also require libraries. So just use a Library in Go?
> easy database CRUD operations?
What's that, ORMs? SQL Generators? They do exist in Go.
ORMs tend to make things more complicated and usually slower. I'd recommend using SQLX. It is a nice half-way point. It eliminates most boilerplate, is going to be sufficiently performant for 99% of cases, and it reduces a lot of cases down to between 1 and 5 lines of code for simple CRUD operations. (Where it isn't fast enough you can easily fall back to using the SQL drivers directly.
I agree 100% with you, and this is how I build my stuff too!
I was just pointing out that framework-less Go projects can have SQLX, ORM, etc, if you want to!