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.
Approov token check fails for requests which do not have the Approov token header: When the Approov Token header is not present then the request cannot be trusted and an error response must be returned.
The JWT library used to check the Approov token must be explicitly configured with the algorithm it should use, 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.
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.
Approov token check fails for tokens with 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.
Approov token check was implemented with 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.
Approov token binding works as expected when used: More about Approov token binding here.
The 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.
All the geographically distributed servers must 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.
Enable Approov monitoring on APIs to get email warnings when pins change: Relevant docs here.
Process is in place to ensure operations team for the backend know about the mobile app 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.
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?
The app code must not store/cache any Approov tokens: The Approov SDK does this internally for you.
The app code must not log Approov tokens in any circumstance, not even in crashes: Use Approov loggable tokens instead for debug help.
If using bitcode for iOS ensure that bitcode mode is enabled: You must have registered the app with the
-bitcode flag or, if you downlaoded the SDK directly rather than through a package manager, you should have used the
-bitcode flag for the download with the Approov CLI.
Retry behavior is implemented for when the app fails to get an Approov token due to 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.
The 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.
The app binary for the release is registered with Approov by following the correct steps 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.
The Approov security policies are the ones you want for production: 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.
The Approov-enabled app works as expected on a random sample of representative devices, checking both new installs and app upgrades if appropriate: Be sure to test the mobile app in a different mobile device from the one you have used for development or remove it from any
whitelist custom policy.
Process is in place to ensure new published versions of the app 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.