Making webhook APIs secure for enterprise with less than 40 chars
•Download as PPTX, PDF•
0 likes•87 views
Making webhook APIs secure for enterprise involves securing both the API provider and consumer. For API providers, this involves grouping events into APIs and only exposing them to approved developers, enforcing TLS, guaranteeing delivery, and keeping logs. For API consumers, it means knowing API providers, securing callback URLs, and using an API gateway to avoid overload. Checklists are provided to help API providers and consumers implement these security best practices.
Recommended
Recommended
More Related Content
Similar to Making webhook APIs secure for enterprise with less than 40 chars
Similar to Making webhook APIs secure for enterprise with less than 40 chars (20)
More from APIsecure_ Official
More from APIsecure_ Official (20)
Recently uploaded
Recently uploaded (20)
Making webhook APIs secure for enterprise with less than 40 chars
- 1. Making webhook APIs secure for enterprise
- 2. About me Liam Forde Co-founder of webhookie – open-source webhook API platform Background in integration development and integration architecture
- 3. REST vs webhook APIs REST API Request-driven Best fit use case – Integrating apps and portals to backend systems “Any new data?” “Here you go!” JSON HTTP over API Provider API Consumer
- 4. REST vs webhook APIs Webhook API Event-driven Best fit use case – Integrating system to system (A2A and B2B) “New Data” API Consumer API Provider JSON HTTP over user-defined HTTP callbacks Http push API Reverse API Web callbacks Other names:
- 6. Discord Hack channel channel Unique URL to post POST/webhooks/{webhook.id}/{webhook.token} application
- 7. Discord Webhook – Not a webhook Discord API Consumer Why do they call it a webhook? • The only security it relies on is a unique URL • early webhook implementations kept it simple and rather encouraged a unique URL as the only security for callback URLs. Calling it a webhook is better than calling it an unsecured REST API.
- 9. REST API Security Request Response Human Perimeter Network Endpoint Application Data Asset API Provider
- 10. webhook API Security Event Human Perimeter Network Endpoint Application Data Asset API Consumer Human Perimeter Network Endpoint Application Data Asset API Provider
- 11. API Provider Concerns Human Perimeter Network Endpoint Application Data Asset API Provider Don’t overexpose! Know your consumers! Avoid eavesdropping! Always deliver! Keep a log!
- 13. Group events into APIs Consumer Group A Consumer Group B Consumer Group C API API EventA EventB EventC EventE EventD 1. Group your events into APIs 2. Expose your APIs only to the developers who should know about them Technologies: ASYNC API Specification IAM
- 14. Home Test Production Know your consumers! API Subscription 1 Subscription 3 Server B Server A Server C Subscription 2 3. Approve new subscription requests
- 15. Avoid eavesdropping! 4. Enforce TLS API Callback server https
- 16. Always deliver webhook gateway Resilient to intermittent outages Recover from downtimes Replay when required Retry strategies ttl fifo Recovery strategies Resend Throttling
- 17. Keep a log
- 18. API Consumer Concerns Human Perimeter Network Endpoint Application Data Asset API Consumer Know your API Providers! Don’t have an open door! Avoid the tsunami! Handshake on a subscription!
- 19. Know your API Providers! allow-lists use or mutual-TLS
- 20. Handshake on a subscription! Confirm intent on subscription API Provider API Consumer create subscription 201 – creation ok Validate subscription with secret 200 – ok with secret
- 21. Don’t have an open door! Oauth 2.0 HMAC API key Basic or Other alternatives or
- 22. Avoiding the tsunami Use an API Gateway Webhook API Callback API GW
- 23. Checklist – API Providers Checklist Action Don’t over-expose 1. Group events into APIs 2. Make APIs discoverable to the right developers Know your consumers 3. Link subscriptions to strong identities 4. Approve new subscription requests Avoid eavesdropping 5. Enforce TLS Always deliver 6. Guarantee delivery with retries, recovery and resend capability Keep a log 7. Keep a record of all events sent to a subscription.
- 24. Checklist – API Consumers Checklist Action Know your API providers 1. Use mutual-TLS or use an allow-list Handshake on a subscription 2. Support confirm on intent protocol (RESTHooks). Don’t have an open door! 3. Secure your callback URL with Oauth, HMAC or less preferred but still better than nothing API Key or Basic. Avoid the tsunami! 4. Use an API gateway with throttling and off-loading capability.
Editor's Notes
- Hi, thanks and great to be speaking at API Secure! Previously I’ve spoken at Api days about why webhook APIs or event APIs are going to become prominent in Enterprise. Today I’m going to cover the most important requirement of using webhook APIs in enterprise… security. (slide: x seconds, total = x seconds)
- But let me first introduce myself, my name is Liam Forde, I’m most recently a co-founder of webhookie - an open-source webhook API platform. Prior to that I’ve spent a significant portion of my career as an Integration architect and developer. As I just mentioned I also spoke recently at API days Helsinki and North about why webhook Api’s are REST APIs perfect side kick. If you want to learn more about webhook APIs I suggest checking that out. (slide: x seconds, total = x min x seconds)
- I ‘ll start the talk with a quick recap of what is a webhook API and why are they important to talk about. All of us here would be familiar with a REST API. REST APIs are great. They have democratized access to data using some clean, simple and accessible technologies – primarily JSON and HTTP. REST APIs are what you would call request-driven APIs in that the API consumers need to call them.
- Webhook APIs are like REST APIs, in that they use JSON and HTTP but they are different in that the API consumer receives the data without having to call them. Rather the API consumer sets up a subscription and the API provider pushes the data to the API consumers when the event occurs. This makes Webhook APIs perfect for data integration needs, synchronising data and automating processes. They are also known by many names And just like REST APIs you describe them with an API specification (OAS or ASYNC API specification) and make them discoverable and self-service. It’s the discoverability, self-service and use of accessible and simple technologies that make them a game changer for Enterprise integration. But if they are going to become more prominent within Enterprise then security is the first thing to address. After all many of the webhook solutions we know today would not pass the security checks of large enterprise.
- The Discord webhook as a good example of this. Discord is a community platform Perhaps some saw this hack in the news earlier in the year. ”Discord hacking is the new newest threat for NFT Buyers.” Read in... It’s about thieves targetting a feature known as a webhook! Both projects were about to distribute rewards to their community members: Monkey Kingdom through an NFT presale on the day of the 21st and Fractal through a token airdrop — essentially a free distribution to early supporters — a few days later.
- Explain the hack - Both projects were about to distribute rewards to their community members: Monkey Kingdom through an NFT presale on the day of the 21st and Fractal through a token airdrop — essentially a free distribution to early supporters — a few days later. Don’t put token in the URL - URLs can generally end up in all sorts of unexpected places (analytics platforms, logs, history etc) that can be easily accessed. In the discord hack they had written a bot that scanned public github repo. URL’s are not treated with the same security processes as passwords and secrets. Conclusion don’t rely on unique URLs as your only form of security for callbacks.
- Explain the hack - Both projects were about to distribute rewards to their community members: Monkey Kingdom through an NFT presale on the day of the 21st and Fractal through a token airdrop — essentially a free distribution to early supporters — a few days later. Don’t put token in the URL - URLs can generally end up in all sorts of unexpected places (analytics platforms, logs, history etc) that can be easily accessed. In the discord hack they had written a bot that scanned public github repo. URL’s are not treated with the same security processes as passwords and secrets. Conclusion don’t rely on unique URLs as your only form of security for callbacks.
- Slack webhooks has the same vulnerability. Repeat again – don’t rely on unique URLs to secure your webhooks
- When it comes to normal REST APIs , the topic of API security is mostly directed towards the API Provider. The API provider is the one that Layers of an onion REST API only is one-sided security I’m not going to talk too much about these layers but
- Webhook security is two sided. So for the rest of this presentation I’m going to take a look at the security concerns from both an API provider and an API consumer perspective.
- Discoverable APIs are a game changer for enterprise and ultimately give comes speed and agility however the downside is that you advertise your capabilities to also unwanted eyes. Therefore, it’s important that you try to restrict making your API’s discoverable to the communities of developers who should now about them. This is particularly important for enterprise. This applies to Events. In many webhook implementations you will have a subscriptions endpoint with the list of events that can be subscribed to. Again the slack events API is an example. If you applied this same pattern to enterprise it would mean that if you got access to this subscriptions API, you could view all the possible events in the enterprise to subscribe to. https://api.slack.com/events
- A better approach is to group your events into APIs allowing you to setup authorizations rules that allow only certain groups of developers to discover them. To describe your APIs you can check out the ASYNC API specification Event APIs can be assigned to consumer groups and you can use identity platforms to manage those groups.
- The great thing with webhooks and in general the pub/sub pattern is that you can quickly and easily setup multiple subscriptions to a feed. So in a normal use case you might want to setup one subscription to push events to your test system and another to push to your production system. Related to over-exposure – this benefit is also a risk. If you give access to a developer to a webhook API which enables them to setup subscriptions well then you also open up the possibility for them to take that data to unauthorized locations. Now admittedly you can’t prevent this completely from happening but you can minimize the risk by at least ensuring that each subscription is approved by the API provider.
- This one is a quick one and in the majority of cases most webhook implementations meet this requirement. TLS is probably the most prominent security technique and ensures that we are delivering our messages to the right server in an encrypted connection. It should always be enforced in enterprise solutions.
- And the primary job of this gateway will be to manage the guaranteed delivery to the subscribers and what subscribers generally demand from a webhook service is that it will be: (click) Be resilient to intermittent outages (click) Recover from downtimes (click) Replay messages when required. This includes a bunch of requirements and concerns that need to considered including: (click) retry strategies – for example how often and for how long should retries occur to be resilient to intermittent outages. (click) time-to-live – is there a time-limit for when this message is relevant. If it is not delivered today is there any point delivering it tomorrow (click) Fifo – is the order of delivery important (click) Recovery strategies – so if my system was down for a while and I want to automatically recover any messages which stopped retrying when i start up – what capabilities does the webhook API service have. (click) Re-send functionality – sometimes downstream systems need to have it sent again because of an issue they ran into on their side. (click) Throttling – different subscribers will have different capabilities. (slide: 40 seconds, total = 12 min 15 seconds)
- Knowing what data your subscribers have received is becoming more important. Not only because of regulations like GDPR but also because it builds trust in your webhook solution.
- Yep, just like the API providers need to know their consumers, API consumers need to know their API providers. (Unlike the picture here, I’m not referring to who the developer was but knowing the API providers severs) When it comes to REST APIs implementing Mutual TLS is tricky, because the client is often a web browser with a user at the end and asking the for an SSL certificate is a jarring experience. However with webhook APIs, we are in the context of system to system integrations, and mutual TLS is not only achievable but also good practice. If mutual TLS can not be achieved then using allow-lists is a solid brute force technique to ensure only those API provider servers can talk to your servers.
- Next up as an API consumer is that you don’t want to unexpectedly receive events to a URL not intended for those events. If subscriptions are not validated then this is a good way for hackers to setup a denial of service account. Find a webhook API that has a high volume of events and send them towards to a URL that they want to take down. Therefore it is good practice to validate a subscripiton. With the provider sending a request to the consumer with a secret and for the consumer to respond with a 200 and the same secret in the header.
- As referenced in the Discord Hack, don’t rely on a unique URL as your only security mechanism. An API consumers callback URL should not be treated differently to a normal REST API endpoint. There should be some authorization security. Even if you have mutual TLS in place many enterprises will look to add another layer of security. The use of a secret that is retrieved from a vault adds another layer. Technologies like Oauth 2.0 client credentials flow or the use of HMAC signature.
- And that is the reason why we have started webhookie – an open source webhook API platform – that can be quickly added to any product, platform or integration architecture. Come and join the project. Thank you. (slide: 15 seconds, total = 15 min 45 seconds) .