Share article:
Why your business needs Enterprise Webhooks
Gone are the days of polling APIs for data, thanks to instant notification mechanisms known as webhooks. At MessageMedia, we love webhooks because they allow you to access data in real-time. For example, webhooks enable you to receive notifications when messages are delivered via the Messaging API. While being incredibly powerful and efficient, webhooks may create some dangerous security vulnerabilities in your application if not taken care of properly.
Just last year, GDPR came into being, Google (Chrome) started calling out non-HTTPs compliant sites and the mandatory data breach notification commenced. This sudden tightening of security shouldn’t come off as surprising. In 2018 H1 alone, the number of data breaches in the United States amounted to 668 with over 22 million records exposed. What were the consequences you ask? Damage to reputation, loss of data and countless financial troubles to fix the breaches. Equifax’s financial breach back in 2017 is estimated to cost them around US$600 million. Security is clearly not a matter to be taken lightly.
If you’ve already read about secure webhooks, you’ll know that generic webhooks create a virtual “door” into your system which can easily be exploited to send malicious data to your system. It’s important to protect your data by ensuring information is coming from verified sources and therefore, protecting against unwanted data from entering your application. While there are steps you can take to secure your webhooks, companies with sensitive data may wish for further protection.
At MessageMedia we believe security should never be compromised which is why we’ve built Enterprise Webhooks. In this blog post, we’ll be talking about how you’re vulnerable to breaches and how Enterprise Webhooks ensures the security of your application.
Life without Enteprise Webhooks
If your system is exchanging data with an external API then chances are you are using webhooks. But what if an outside party knows the URL through which the external API is using to communicate with your application? Let’s say you’re working in a bank and every transaction needs to be sent to the URL
https://mynotsosecurebank.com/transaction
where it’s processed. So, if you wanted to transfer $1000 to your savings account, the payload sent to the URL would look like this:
{
“name”: “Ibrahim Tareq”,
“sender_account_no”: “1234 1234”,
“amount”: “1000”,
“receiver_account_no”: “5678 5678”
}
Now if I’m a disgruntled ex-employee, I can send a fake payload to
https://mynotsosecurebank.com/transaction
which might look like this:
{
“name”: “Ibrahim Tareq”,
“sender_account_no”: “1234 1234”,
“amount”: “1000”,
“receiver_account_no”: “9010 9010”
}
Notice how it looks exactly the same as the genuine payload. What’s going to happen now is the system is going to process the data and transfer $1000 from your account to mine. Now that’s just me playing nice but an actual hacker could potentially transfer hundreds of thousands of dollars from your account. And it doesn’t stop there.
Let’s take a look at another example. Picture yourself working at the taxation office in the department where you’re responsible for paying out tax returns to the hardworking citizens of the country. The core application used to perform the calculations and do the heavy lifting is integrated with an external API and they’re using webhooks to communicate with each other. The taxation office is a little smarter than the bank so what they’ve asked the external API team to append a shared secret to the URL. So rather than looking like this
https://mykindofsecuretaxoffice.com/return
it looks like this
https://mykindofsecuretaxoffice.com/return?secret=a^dajsd!cm
The purpose of having this shared secret is now the taxation office’s application can verify and know that the URL from which it receives data MUST have the shared secret appended to it or else it’s not authentic. That’s great but does it secure your application? Debatable. Since the shared secret will remain the same each time data is exchanged, this means that if anyone manages to intercept the payload (MITM attack), they’ll get their hands on the shared secret which means they can start sending fake payloads to your system. You can imagine the amount of damage that can be done to the taxation office if such a scenario were to ever occur.
Life with Enterprise Webhooks
Enable Enterprise Webhooks and you can forget about having to worry about any of the above scenarios. Once enabled, each and every webhook sent by MessageMedia will be signed. In the first banking scenario, this means that unless the webhook data returned to the bank is NOT signed, the transaction will not be processed by the system. Think of Enterprise Webhooks as a guard that stands at the “door” of your application and each time a delivery comes through, it checks to ensure it’s coming from the right sender. Here’s a simplified example of what a signed webhook would look like:
X-MESSAGEMEDIA-SIGNATURE: YdhajTA1p68BrxtWq0hvupEQxA4eliL2rA0t
{
“name”: “Ibrahim Tareq”,
“sender_account_no”: “1234 1234”,
“amount”: “1000”,
“receiver_account_no”: “9010 9010”
}
The X-MESSAGEMEDIA-SIGNATURE is an additional header that’s added to all webhooks. There are also other headers that are added but I’ve left them out to keep this blog post simple and easy to understand. Each and every webhook will have a unique signature that can ONLY be decrypted or “unlocked” using a key that is associated with your account. This means that even if someone manages to successfully launch a MITM attack, they won’t be able to view the content of the message as it’s encrypted. Can they decrypt it? No, as they won’t have the key that’s required to do so.
As the saying goes, you can never be too careful. Cause if you aren’t you might be the victim of a security breach, having to face the wrath of angry customers and spending thousands, if not more, trying to cover up the costs of the breach. Webhooks albeit being incredibly useful and effective aren’t quite secure especially for government organisations and banks. But now using Enterprise Webhooks, you can close that gap and ensure your application is less-prone to security breaches.
