Support ability to disable Dynamic and Endpoint badges for self-hosters

[calebcartwright]

📋 Description

Provide a configuration/setting on the badge server that allows for the dynamic and endpoint badges to be disabled.

Rationale and use case

This is obviously a self-hosting only type of scenario (we'd never need it for the main Shields.io deployment), but I'm increasingly convinced this would be a valuable feature for certain types of self-hosting use cases.

The native/dedicated-route badges are all relatively straightforward and easily auditable to determine the full scope of data exposure (e.g. self-hosting teams can easily review the badge offerings and identify the data points that could potentially be returned from some other tool/system via a badge/json response/etc. that a self-hosted badge server could provide). However, the dynamic and endpoint badges are inherently, by design open ended.

With this type of feature, a team could more confidently deploy a self-hosted badge server, even one that's internet-facing, with a clearly defined risk profile (i.e. we know we're exposing basic metadata like issue status from our internal Jira server, as opposed to any arbitrary API within our corporate network).

[chris48s]

I hadn't really thought of this being used as a way to exfiltrate data, but you are right. If I know the URL of a JSON document on your network and its structure and your public shields instance can contact the server it is on, I could read the whole document one value at a time via the dynamic JSON badge by jsonpath-ing my way through the tree. You do need a fair bit of extra knowledge to pull off that attack, but it is conceivable.

I agree this would be a useful setting.

Assuming we introduce it, do you think endpoint/dynamic badges should be be enabled or disabled by default? Disabled by default is obviously safer, but also it would be a breaking change for existing users. I feel like now that we have tagged releases with a changelog for each release, making a breaking change is a bit less of a big deal now.

[calebcartwright]

My inclination would be to keep it on by default, and just add this new feature as an opt-out. I suspect there are more self-hosted deploys where this is moot (e.g. running on a corporate intranet), and there's comparatively fewer cases that would need to lock it down