The "other parsers" in stdlib are gob and encoding/xml.

Gob is a format made for Go, so it does not have a field naming convention mismatch; what's on wire is the Go convention.

encoding/xml isn't really structured as a "convert between equivalent-shaped structs and a message" utility, its struct tags are more like a query language, like a simpler cousin of XPath. Most real-world code using it does things like

    type Person struct {
        FirstName string   `xml:"name>first"`
        LastName  string   `xml:"name>last"`
    }

    {"email": "jdoe@example.com", "name": "John Doe"}

    type Person struct {
        Email string
        Name  string
    }

I think you and I read a different article. For example, about treating JSON keys without case sensitivity:

> In our opinion, this is the most critical pitfall of Go’s JSON parser because it differs from the default parsers for JavaScript, Python, Rust, Ruby, Java, and all other parsers we tested.

It would be kind of difficult to argue that this is not about Go.

Don't get me wrong, I love Go just as much as the next person, but this article definitely lays bare some issues with serialization specific to Go.

I don’t think the title is clickbait. You’re fixating on just one example in the post, but the others demonstrate a clear pattern: there are footguns in Go’s various parsers, including forms of malleability or flexibility that enable parser differentials.

This isn’t intended to be a ding against Go; it’s a universal problem across programming languages (otherwise there’d be no differentials at all). But they’re worth noting, and I think the post amply demonstrates their security relevance.

I disagree.

It was a bad design choice to allow JSON keys with different capitalisation and to serialise all public struct members by default.

These decisions can easily result in the creation of an insecure system.

Of course it's about Go. They decided to build not just opt-out unmarshaling of objects, but fragile opt-out.

See eg rails' strong params for the opposite approach: opt-in.