Scribd
Upload
9 views

Security of API

Uploaded by

maduhkelly1
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
9 views

Security of API

Uploaded by

maduhkelly1
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

SECURITY OF API

1. Web hook security.

A web hook is simply a URL where API providers sent a post when something happens e.g. stripe sent
notifications about new payment to web hook URL.

Securing web hook is slightly different from securing web api coz webbook url are generally publicly
accessed to on the internet therefore its important for developers to ensure that post request actually
came from the stated sender. In the absence of such a verification, an attacker can forge a request to
the web hook URL.

The common practices to ensure web hook security include:

1. Verification tokens

This is a secrete shared between applications and API providers.


Applications match the token received as part of the request with recorded value, if don’t match,
application ignores the request.
This approach is easy to implement from both API providers and developers perspective.
The weakness is that it offers limited security coz they are sent in plain text with every request.
If token is leaked or compromised, an attacker can forge web hook request.

2. Request signing and web hook signature.


Signatures are among the most common ways API providers choose to secure web hooks.
Web hook payloads are typically sign by computing a harsh-base message authentication code of a
shared secrete plus the request body and the signature is sent as part of request header. Applications
then verify the authenticity of the request by computing same smac and comparing it to the value sent
in the header. Stripe, git etc use this mechanism.

3. Mutual transport layer security.

When you connect to an https URL with transport layer security handshake protocol, the server sent its
certificate to the client. The client then verify the server certificate before trusting response.

With mutual tls, server and client both authenticate with each other. Server sent client a certificate
request, client (web hook provider) responds with certificate. Serve verify the certificate before trusting
request.

Mutual tls is applied in b2b application.

4. Thin payload and API retrieval.

One fundamental problem is that all these methods rely on developers to do the righ thing. They do not
enforce authentication.

Different application developers can follow different standards and it’s difficult to determine whether
they are verifying web hook request. More secure option is to send limited information in the payload
indicating to the application that something to retrieve the full event, the application will need to
make…
The key benefit is that even if application does not verify the web hook they will receive the web event
only after making regular authenticating request to web API.

Best practices in web hook security.

When building web hook,

1. Avoid sending sensitive information as part of web hook payload, therefore use authenticated API
request to send sensitive information.

2. When signing web hook include time stamp. This way, application can implement checks for replay
attacks.

3. Support regeneration of shared secretes that are used for verification or for signing we hook so that in
case of a compromised secrete, an application developer can rotate this secret and ensure authentity of
future reques

4. Provide developers with sdk and sample code that verify authenticity of the we hook request

You might also like