RE: Securing a second api key that must be passed in a header

Richard Nolan — Sat, 12 Nov 2022 18:05:25 GMT

That's an approach that I've hashed out with others. We've also gone back to the architects of this network configuration with some questions.

My main concern here is that some escalation of privilege attack on an Appian environment could necessarily then have an escalation on another system.

The advantage of encrypting the local constant based key is that it puts the vulnerable key in the admin console, which I like. It does however feel clunky. I'd rather the underlying architecture owned this problem.

Thanks for your response!

RE: Securing a second api key that must be passed in a header

Stefan Helzle — Sat, 12 Nov 2022 09:43:26 GMT

Any header in HTTP is clear text, that is why we use SSL to encrypt the transport.

The encryption functions plugin can encrypt and decrypt strings using a static key stored in the secure credential store. So, you could put the encrypted API key into a constant and decrypt it on demand using that static key. That would at least increase the effort to get the access to the API key.