knadh / koanf

Simple, extremely lightweight, extensible, configuration management library for Go. Support for JSON, TOML, YAML, env, command line, file, S3 etc. Alternative to viper.
MIT License
2.71k stars 150 forks source link

Support validation #40

Closed MadsRC closed 3 years ago

MadsRC commented 3 years ago

The library currently does not seem to support input sanitation as "first-class citizens".

The entire library centres around accepting user input from different sources. One of the golden rules of defensive programming (or just sane coding practices, as some would say...) is to never trust user input.

Currently, if I want to validate the my users input (other than validating by type), I'll have to create some unholy, ham-fisted hack by combining koanf with go-validator (I'll be honest, I haven't looked at actually doing that yet as I just recently stumbled upon koanf).

Would you guys be open to extending koanf to support something like go-validator? I'd be happy to help create the code, I'd just need some guidance as to how you guys would like it integrated.

knadh commented 3 years ago

@MadsRC koanf is an internal / backend configuration management library. Combining end user input with backend configuration of an application is an unusual scenario. For the same reason reason, validation is outside the scope of the library. If your usecase really needs to mix end user input with backend config, it's best if you validate it separately like you suggested, using something like go-validator.

MadsRC commented 3 years ago

Thank you for getting back to me. Active maintainers that can evaluate and decide whether or not to include a feature is something that I can only respect ;)

However, that does not mean that I agree, and I'd like to present my arguments. But please do note that I recognise the sovereignty of the active maintainer.

You state that the module is for internal / backend configuration, and that it's unusual to combine backend configuration with end user input. Your modules core functionality is: Accept input from difference sources, make it available in the application. The persons configuring the backend of an app is still users of the configuration management library.

Good, sound security practices dictate that all user input is to be sanitized. If anyone is able to write to the sources that koanf reads, it would be possible to exploit a potential weakness in the module or any underlying routines.

You could say that one can put a higher degree of trust into the configuration sources, as you'd have to "own" the server to do any changes (As opposed to accepting arbitrary user input over HTTP for example...), but with the recent traction of the "Zero Trust" movement, I'd say that there is some serious security winnings if all input was treated with Zero Trust and supported some form of sanitation/authorization.

I'll close this here as there's no need to keep kicking a dead horse ;)

Oh, and thank you for creating Koanf!

knadh commented 3 years ago

I think that's a bit of a weak analogy :) By that logic, one would expect a CSV reader lib that reads arbitrary CSV blobs or a DB driver that funnels data back and forth between the world and a DB to also have built-in support for custom validations for user inputs. But clearly, that would fall outside the scope of those libs.

If it's any consolation, depending on the format of data that koanf reads (TOML, YAML etc.), the respective parsers inherently validate and sanitize types. In addition, koanf's getter functions such as String(), Int() etc. provide internal sanitization and type safety.

Finally, for the exact same reason, that koanf can support arbitrary data sources and formats, it would be very difficult to even build a go-validator like layer on top of it.