It has been reported that Spotify has stopped working properly, according to users. A strange bug appears to make the iPhone version of the app crash as soon as it is opened. Spotify does not appear to have pushed out a new update to the app. Instead, the issue appears to be a consequence of problems with Facebook’s developers tools. The same issue has led to problems at a wide variety of apps. There appears to be no simple fix for the issue. Deleting and re-installing the app, for instance, does not solve the problem.
Modern applications are a combination of proprietary code, open source software and increasingly third-party APIs. Throw in some configuration settings, and you have an application. Those third-party APIs often do very important things for the application, such as supporting a social media authentication token. Most of the time this is a good thing since it allows the application developers to focus on making their software really cool and not reinventing something that everybody needs. While there has been increasing attention around keeping up with the security of open source components in recent years, the API side of things hasn’t seen as much focus. Part of that has to do with the reality that most API providers want their users to keep using their APIs and will do almost anything to keep the APIs functioning. This of course can lead to some serious problems if the API needs to change due to security issues, or becomes unavailable for any number of reasons.
This is exactly what users of popular apps like Spotify, Tinder, and Pinterest, using the Facebook SDK are experiencing. While the Facebook team are working to resolve the issue, this incident highlights an important set of security implications for any app using third-party APIs and SDKs – what happens to your app if the API fails? While some apps are designed to work in airplane mode and have a concept of offline operation, that’s not the same as a critical API failing. When an API fails, the error message returned might be in an unexpected format – say readable to a human but not software. When bad data is encountered, the app may crash or perhaps write information to a log file. The crash or log file might contain data that would be helpful to a developer, such as a username or access token, but that same helpful information might be classified as personally identifiable under one or more privacy laws. This is an example of how a decision made during development could have implications for compliance teams and end users. No business wants to have users complaining about their apps crashing, but things get worse if your legal team needs to be involved.
Solving for this problem is easily done through the use of ongoing architecture reviews and updated threat models all performed with an eye on external API usage. The threat models will look at the data transferred and the architecture reviews will look at the behaviour of the app when faced with the unexpected, such as a failed API or transient network connection.