Shared Secret

In our research, 10% of the webhook providers use Shared Secrets — in the form of Basic Authentication, shared credentials, bearer tokens, or a verification token — for authentication. In this method, the webhook provider and listener share a common secret used exclusively to authenticate webhook requests:

1. On webhook requests, the provider sends a webhook notification containing the message plus a shared secret in a pre-defined header variable or the Authorization header using the Basic Auth format ( Authorization: Basic <"username:password" in base64> ):

   app.post('/webhook', (req, res) => {
     
     // get authorization header (Basic <value>)
     const b64auth = (req.headers.authorization || '').split('Basic ')[1] || ''
     // Get login and password
     const [login, password] = Buffer.from(b64auth, 'base64').toString().split(':')
   
   
     // Verify login and password are and correct
     if (login && password && 
         login === process.env.WEBHOOK_LOGIN && 
         password === process.env.WEBHOOK_PW) {
       // Webhook Authenticated 
       // process and respond...
       res.json({ message: "Success" })
     }else{
       res.status(401).send('Authentication required.')
     }
   })
   

2. The webhook listener validates the value in the request versus the shared secret. Only requests with the correct secret are processed.

Basic Authentication, or shared credentials, or verification token on webhook requests

This security method addresses only the webhook service authentication and does not implement any control on message integrity. Even with HTTPS, the shared secret is processed in clear text, increasing the risk of the secret getting compromised.

Therefore, their use should be avoided in production or used only with compensatory controls — such as IP Restrictions and callback requests — to mitigate risks.