Why Sonic?

[gregriff]

Recently I evaluated Gin for use in a personal project. I was surprised to see that the first dependency of Gin is sonic, a JSON serialization/de-serialization package developed by the Chinese company Bytedance.

41% of the Sonic repository is Assembly. Almost every file I viewed used the unsafe package. Given that this package is used to validate user input (probably the most common attack vector), is this not a security concern for users of Gin?

[ismaildasci]

Good question! Here is the context:

Why Sonic?

• Sonic is significantly faster than standard library encoding/json (2-5x in benchmarks)
• For high-traffic APIs, JSON serialization can be a bottleneck
• ByteDance uses it in production at massive scale (TikTok backend)

About the unsafe package:

• Using unsafe is common in high-performance Go libraries
• The Go standard library itself uses unsafe extensively
• Its not inherently insecure - its just bypassing Gos safety checks for performance

Security considerations:

• Sonic is well-tested and widely used
• The assembly code is for SIMD optimizations (faster parsing)
• JSON parsing vulnerabilities are rare compared to other attack vectors

If you prefer standard library:
Gin supports build tags to use different JSON libraries:

go build -tags=go_json ./...

Or use jsoniter:

go build -tags=jsoniter ./...

Bottom line:
The security risk from Sonic is minimal. Input validation should happen at application level anyway, not in the JSON parser. But if you are uncomfortable, you can easily switch to standard encoding/json with build tags.