Test signature verification
If your app has signature verification check enabled, you must ensure that the verification logic is implemented correctly before submitting your app for review. You can do this by running a signature verification test via the Developer Portal.
The signature verification test works by sending a combination of valid and invalid requests to your app's endpoints. To pass the test, the app must respond to each request with an expected status code. The expected status code depends on the test and the endpoint.
Disabling verification checks
While we consider it a best practice for all apps to leave signature verification checks enabled, you're allowed to disable them if your app uses public APIs, doesn't handle user data, and doesn't require authentication.
If signature verification checks are enabled, you can only submit an app for review after verifying its requests. If you disable signature verification checks, you can only submit an app for review after explaining why you're disabling the checks and providing the URL of the public API's documentation. This applies to both public apps and team apps.
To disable signature verification checks:
- Navigate to the Verification page.
- Toggle the Enable Signature Verification Checks switch off.
- In the Reason for disabling signature verification checks field, explain why you're disabling signature verification checks.
- In the Public API Documentation URL field, enter the URL of the public API's documentation.
Running the test
If you navigate to an app's Submission page, the signature verification test runs automatically.
To run the test manually:
- Navigate to an app via the Developer Portal.
- Click Verification.
- Click Run signature verification test.
You can re-run the test on-demand, but to prevent people from using Canva for a DoS attack, there's a limit of 100 requests per 24-hour period. If you exceed this limit, an error occurs. The more endpoints the app supports, the faster you'll reach the limit.
Understanding the results
After running the test, a table appears that contains a list of endpoints that the app might support. This list is based on the app's extensions.
For each endpoint, Canva runs the following tests:
Canva sends a request to the endpoint with an invalid request signature. This simulates what happens when someone other than Canva sends a request to the app.
Canva sends two requests to the endpoint with invalid timestamps. One of these timestamps is too far in the future, while the other is too far in the past. This simulates what happens during a replay attack.
Mixed valid/invalid signatures
Canva sends a request to the endpoint with a comma-separated list of request signatures, only one of which is valid. This simulates what happens when you regenerate the app's client secret.
For each test result, Canva shows the following status codes:
- Expected - The status code that Canva expects to receive from the endpoint. In some cases, more than one status code is considered valid.
- Received - The status code that Canva received from the endpoint when running the test.
When the Received status code matches an Expected status code, the test passes. If the codes don't match, the test fails. This indicates an issue with how the endpoint is verifying requests.
The Expected status code will always be one of the following:
If the Received code doesn't match and you're not sure why, see HTTP response status codes for a complete list of possible status codes. The descriptions may help you identify the reason for the mismatch.
404 status codes
For some tests, the
404 status code is valid. This is because some endpoints are sometimes optional. For example, a publish extension that uses the Basic layout doesn't support the following endpoints:
But these endpoints still appear in the signature verification test, regardless of how the extension is configured. Other endpoints are always optional, so a
404 status is always valid.