Signature validation-V3
All requests from Plivo’s Voice platform to your application server contain X-Plivo-Signature-V3, X-Plivo-Signature-Ma-V3, and X-Plivo-Signature-V3-Nonce HTTP headers. To verify that the request to your server originated from Plivo and that it was not altered en route, you may generate your own request signatures and compare them with the X-Plivo-Signature-V3 or X-Plivo-Signature-Ma-V3 HTTP headers passed by Plivo.
Signature generation logic
Plivo signs all HTTP requests from its servers to your application server, and assembles the request to your application server by concatenating the final request URL (the full URL with the scheme, port, and query string) and any POST parameters.
- If your request is a POST, Plivo will take all the POST parameters, sort them alphabetically by name (using Unix-style case-sensitive sorting), and append the parameter name and value pairs to the end of the URL.
- If the request is a GET, the final request URL will include all of Plivo’s request parameters appended to the query string of your original URL.
Example:
If your application URL is https://example.com/abcd?foo=bar and the list of Plivo POST parameters is:
Then the complete assembled request string would be:
Concatenating with nonce value
The assembled request string from this step is then appended with a randomly generated nonce string that’s unique for every request. This string is passed separately in the HTTP header X-Plivo-Signature-V3-Nonce as part of the HTTP request to your application URL.
Example:
If the randomly generated nonce value is
then this is how the request string would look after appending the nonce to the previously assembled request string.
Since nonce values are unique, they can help protect your application server from replay attacks.
Signing with Auth Token
The output of this step is then signed using HMAC-SHA256 and your Plivo Auth Token as the key. The resulting signed hashes are Base64-encoded and passed in HTTP headers with the request.
X-Plivo-Signature-V3 is generated using the Auth Token of the account or subaccount associated with the request entity.
For example, if the request is for an incoming call to a Plivo phone number mapped to one of your subaccounts, then that subaccount’s Auth Token will be used when generating X-Plivo-Signature-V3.
X-Plivo-Signature-Ma-V3, on the other hand, is always generated using the Auth Token of your main Plivo account.
Note: If you have more than one active Auth Token for the associated account or subaccount, Plivo will generate a signature using each of the active Auth Tokens and pass a comma-separated list of the resulting signatures to the application server (for example, X-Plivo-Signature-Ma-V3: <Signature signed with Token 1>,<Signature signed with Token 2>).
Validating requests on the application server
Plivo Server SDKs include helper functions to validate incoming requests with X-Plivo-Signature HTTP headers.
Code
When someone makes a call to a Plivo number, Plivo requests the webhook associated with this code. The code runs and returns a Speak XML element if it can authenticate the request sent. If the validation fails the call will terminate, since no XML is returned to the Plivo server.
You may also write your own request validation code by generating request signatures based on the signature generation logic and validating them against the signatures passed by Plivo in the HTTP request headers.
Deprecation notice: X-Plivo-Signature-v2
If you’re still using Plivo’s V2 signatures to validate requests, we highly recommend switching over to X-Plivo-Signature-V3. V3 signatures offer improved protection against manipulation of POST request payloads en route.