A checklist of things you should consider before going live with Approov in blocking mode, so that failed Approov tokens 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. Some examples of using cURL requests with Approov tokens can be found here. 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.
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. Relevant docs here.
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 all use the same certificates or that they share the same public key. If using different certificates then you can add the pins for each of them with the Approov CLI tool. Relevant docs here.
2.3 Enable Approov Monitoring on APIs for Email Warnings when Pins Change: Relevant docs here.
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 normal renewals where possible. Relevant docs here.
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 Binary Registered Appropriately for Android and/or iOS: Relevant docs here. Bear in mind that Android releases using Google Play signing (including App Bundles) need to follow specific steps, including the addition of the app signing certificate to Approov.
3.3 Process in Place to Ensure New Published App Version are Registered: Ensure that the team responsible for releasing apps to the app stores are aware of the need to register the version of the app with Approov before going live with that version. Note also that the registration should be a permanent, rather than temporary, one.
3.4 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 new installs and app upgrades if appropriate
3.5 Approov Security Policies are Production Suitable: Relevant docs here. 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.
3.6 For iOS If You Are Using Bitcode: You must have registered the app with the -bitcode flag or, if you downloaded the SDK directly rather than through a package manager, you should have used the -bitcode flag for the download with the Approov CLI.
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: Relevant docs here (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.