A checklist of things you should consider before going live with Approov in blocking mode, so that failed attestations will impact the API calls that the app is making.
Issues related to the backend Approov token check integration.
1.1 Approov Token Secret is not Hardcoded: Never hardcode the Approov token secret in your code. If it has been leaked then change it with the Approov CLI.
1.2 Approov Token Check Fails for Requests Without Approov Token: When the Approov Token header is not present then the request cannot be trusted and an error response must be returned.
1.3 JWT Library Explicitly Sets Expected Algorithm: This algorithm is usually HS256. Some JWT libraries are vulnerable to the none algorithm attack of setting the JWT header to alg: none, thus making any token succeed in the check.
1.4 Approov Token Check Fails for Expired Tokens: Even if the Approov token has a valid signature it must not pass the check if the token has expired. The request must not be trusted and an error response must be returned.
1.5 Approov Token Check Fails for Invalid Signatures: You can use the Approov CLI to generate invalid tokens, see docs. Then use cURL, Insomnia or Postman to build and send the requests as if it was your mobile app. See some examples of using cURL requests with Approov tokens. Replace the URL with your own one and the token with the one you generated with the Approov CLI. Another option is to use a mobile app not registered with the Approov cloud service, because it will always get invalid Approov tokens.
1.6 Approov Token Check has a Bypass Mode: Bypass mode means the token check is performed but the request always succeeds, even when no token is presented. This is especially useful for when going to production for the first time with Approov until you are confident the traffic is being properly attested, and that all versions of the app being used have Approov integrated. This can also be used to temporarily bypass checks in an emergency situation.
These are only relevant if you are using explicit certificate pinning rather than the default managed trust roots.
2.1 API Backend Production Domain has Been Tested: Relevant if you are using different API domains between development test and production. Ensure production endpoints have been tested, especially with respect to their pinning.
2.2 Geographically Distributed Servers use the Same Certificates: When you have an API backend that is distributed geographically it’s important to ensure that a pin is added for all the different certificate keys used by servers that handle the associated requests. If all the servers use the same certificate or use certificates signed with the same public key then a single pin will be sufficient. If there are certificates signed with different keys then a pin must be added for each of the different keys that are used, see Adding an Explicit Pin.
2.3 Enable Approov Monitoring on APIs for Email Warnings when Pins Change: See API monitoring.
2.4 Process in Place to Ensure Backend Operations Know About Pinning: Ensure that the team is aware that any rotation of certificates that changes the public key will require new pins to be pushed out to apps beforehand to avoid any downtime. Attempt to use the same public key on renewals where possible, see Managing Dynamic Pinning.
Issues related to the Approov mobile app integration.
3.1 App Upgrade Strategy Identified: If you have a pre-existing mobile app using the same API endpoints that are protected with Approov in the new version, you need to consider your upgrade strategy. Old versions of the app cannot pass the Approov check, and some users might not upgrade their app immediately. Can you block them after a time period and/or send a force upgrade message to those users?
3.2 App Release Signing Certificates Added for Android and/or iOS: You need to ensure that the app signing certificates for Android and iOS realses have been added to Approov. You will need to add the release certificates with auto registration. If not then app releases will need to be individually registered.
3.3 Approov Enabled App Tested on a Random Sample of Representative Devices: Be sure to test the mobile app on a different mobile device from the one you have used for development or remove it from any always-pass custom policy. Check both the new app install path and, if applicable, the upgrade path from an older verion of the app.
3.4 Approov Security Policies are Production Suitable: See security policy documentation. In particular if you are going to production with default policies then this means that rooted Android and jailbroken iOS devices will not be issued with valid Approov tokens, and this may impact some legitimate users. Do not use the annotation policy all in production.
These items are only relevant if you have integrated the Approov SDK directly, rather than using one of the Mobile App Quicksarts.
4.1 App Code Must Not Store/Cache Approov Tokens: The Approov SDK does this internally for you.
4.2 App Code Must Not Log Approov Tokens in Any Circumstance: This must not happen in any circumstance, not even in crashes. Use Approov loggable tokens instead for debug help.
4.3 Approov Retry Behavior Implemented for No/Poor Network Connectivity: Handle token fetch errors (look for POOR_NETWORK). If using a frontend quickstart then this is normally implemented as some form of IOException in the interceptor that should use the normal retry mechanism.
4.4 App Handles Pinning Changes Correctly: Set the pin mode for the app to block while it is running and check this causes pinning fails (this may take up to 5 minutes after the next Approov token fetch). The app should also store a new dynamic configuration with bad pins. Now, restart the app and check that the first pinned API request it makes also fails. Now revert the pin mode to the default “pin” value, wait up to five minutes for the next Approov token fetch and then check that the mobile app allows continued operation, at least after a further 5 minutes and the next Approov token fetch.