Scoped API keys and signed webhooks: least privilege, built in

Until now, an API key in ShadowTrackr could do everything your account could do. That is convenient, but it is not how you want to hand out access to a script, a SIEM or a colleague's dashboard. We added two things to fix that: API keys with a limited scope, and HMAC signatures on webhooks. Both help with the security measures that EU regulation asks of you.

Scoped API keys

When you create an API key, you now choose what it is allowed to do. A key for your reporting dashboard only needs to read. A key for a ticketing integration might only need to read findings. A key that can change settings or delete things is something very few integrations need.

Some examples of how this works in practice:

• Read-only key for a BI tool or dashboard. If it leaks, nobody can change anything in your account.
• One key per integration. If you stop using a tool, you revoke its key and nothing else breaks.
• Narrow keys for contractors and partners, with only the access they need for the job.

Existing keys keep working as before. You can replace them with scoped keys when it suits you. The API documentation lists the available scopes.

Signed webhooks (HMAC)

An alert can call a webhook, but until now the receiving side had no way to know that the call really came from ShadowTrackr. Anyone who found your endpoint URL could send it fake alerts.

You can now turn on HMAC signing for a webhook. ShadowTrackr calculates a signature over the payload with a secret that only you and ShadowTrackr know, and sends it in a header with every call. Your endpoint calculates the same signature and compares. If it does not match, you throw the request away.

This gives you two things:

• Authenticity. The message really comes from ShadowTrackr.
• Integrity. The payload was not changed on the way.

The secret is stored encrypted and shown only once, like the custom header values. It works with all payload types, so it also covers JSON results, Splunk HEC and the rest. The documentation has a short verification example you can paste into your own code.

Why this fits EU regulation better

Regulation like NIS2, DORA and the GDPR does not tell you which header to use. It does expect you to show that you control who can access what, and that you protect your data in transit and know where it came from. These two options map onto that quite directly:

• Least privilege. NIS2 asks for access control and risk-based security measures, and the GDPR asks for appropriate technical measures (Article 32). A key that can only do its one job is the simplest way to show this.
• Smaller blast radius. If a key leaks, the damage is limited to its scope, and you revoke that one key. That makes incidents easier to contain and easier to report.
• Supply chain and third parties. NIS2 and DORA both put weight on third-party risk. Giving a partner a narrow key instead of full access is a control you can explain to an auditor.
• Integrity of security data. Alerts often trigger real actions: a ticket, a page to an on-call engineer, a firewall change. Signed webhooks make sure those actions are triggered by real alerts only.

To be clear, no feature makes you compliant on its own. What these two do is give you controls you can point to, instead of a shared key and an unauthenticated endpoint. ShadowTrackr is hosted in Germany and run by an EU company, so your data stays inside the EU while you do this.

What to do next

1. Make a list of the places where you use a ShadowTrackr API key.
2. Create a scoped key for each one, with the least access it needs, and revoke the old key.
3. Turn on HMAC signing for your webhooks and add the verification to your receiving endpoint.