Sensitive keys, kept off the wire.
Stop sensitive API keys from being used from browsers or non-allow-listed IPs — so a key that escapes into client code or an attacker’s infrastructure simply stops working.
1. Keys leak into the worst places
Sensitive keys end up where they should never be: embedded in front-end JavaScript, committed to repositories, pasted into logs, exfiltrated to an attacker’s server. The defense is not only to prevent the leak but to ensure the leaked key cannot be used from those places — a key that only works from a registered server, never a browser, is far less valuable to steal.
2. Bind the key to its rightful context
Two controls do most of the work: refuse to honor sensitive keys presented from browser contexts, and bind keys to allow-listed IP ranges so they authenticate only from expected infrastructure. Together they turn key leakage from a critical incident into a non-event — the stolen key authenticates from the wrong place and is rejected.
3. How B5 Secure handles it
B5 Secure prevents sensitive keys from being used from browsers or non-allow-listed IPs, working with scoped Service-Keys and the IP firewall so a leaked key’s blast radius is bounded by where it can be used as well as what it can do.