What GDPR Means For API Developers Art Anthony March 19, 2020 Introduced in 2016, and implemented in 2018, GDPR (General Data Protection Regulation) was introduced to give individuals throughout Europe more control over their personal data. Compliance caused plenty of headaches for businesses, both inside and outside of the EU, with many frantically sending out batch emails to confirm that individuals had opted in to hear from them. At the other end of the scale, some sites and services blocked out European users completely. Linn Nordwall, from Sweden’s Delphi law firm, spoke at length on the impact of GDPR at our 2019 Platform Summit. We’ve seen a surge of personal data breaches in recent years, and Linn outlined the impact of some of those breaches as they relate to GDPR. In this article, we’ll see why GDPR compliance should be the responsibility of everyone within an organization by looking at the impact of some recent data breaches. However, it’s easy to make the case that APIs are an obvious weak spot for cyberattacks focused on intercepting data, so we’ll also showcase tips on how to bolster your data protection efforts. Watch Linn Nordwall from Delphi present at the 2019 Platform Summit in Stockholm: Learning From Past GDPR Headlines Linn provides a couple of examples of the outcomes of recent data breaches that made the news. These include British Airways, who face an intended fine of £183,390,000 for redirection to a fraudulent site plus a class-action lawsuit, and Marriott Hotels, who faced an intended fine of £99,200,396. What’s notable about Marriott’s case, particularly for API providers, is that the offending breach of security already existed in a company acquired by Marriott. Because Marriott failed to undertake sufficient due diligence, the breach is treated as their fault. Linn advises that “before you buy a company, or integrate a part of a company into your security systems, you should always make sure that there are no ongoing breaches in this company beforehand.” That’s easier said than done, of course, since breaches don’t always become apparent until further down the line. Plus, there isn’t exactly a specific set of guidelines for GDPR compliance designed with API developers in mind. With regards to the industry as a whole, protecting yourself means following (and only working with other companies that follow) best practices like these: Using SSL and data encryption (both in transit and at rest) Password hashing Avoid exposing information on URLs Pseudonymization of any real user data to be used for testing on dev or staging machines Consider the inclusion of timestamps in requests Avoid exposing API keys Beyond the risk of data breaches, there’s also the fact GDPR means you need to be able to provide information on who you have shared personal information with if requested by your users. That’s certainly a consideration for those who provide open APIs, as this may not necessarily be information that you’re able to track down with any sort of ease. Also read: Building GDPR Compliant APIs With OpenID Connect How to Handle Personal Data Breaches Linn defines a personal data breach, in legal terms, as a “breach of security leading to, for example, destruction, loss, unauthorized disclosure of or access to personal data.” She provides the examples of a lost device, sending an email to the wrong recipient, a successful phishing attack or a failed integration. Obviously, that last point is key when talking about APIs. We’ve written before about how a “leaky API” can kill your business directly, but GDPR violations are an example of how it might do it indirectly as well. It’s easy to see how a team member might risk non-compliance by building or working on an API without the proper knowledge of which personal data they’re legally allowed to use. GDPR not only dictates how data should be handled but also how data breaches should be reported and dealt with: Notification to the supervisory authority – data controller’s responsibility to report without undue delay, not later than 72 hours of becoming aware – unless unlikely to result in a “risk to the rights and freedoms of natural persons” Notification to data subjects – without undue delay if “high risk to the rights and freedoms of natural persons” Documentation – circumstances, effects of the incident, corrective measures In Sweden alone, 6053 personal data breaches were reported between 25th May 2018 and November 2019, with the Swedish Data Protection Authority launching investigations into reported cases. Knowing who you need to report a breach to is vital because, as we’ve seen above, time is of the essence when a breach does occur. In the UK, for example, companies need to report to the ICO. “Knowing how to deal with a personal data breach is important,” Linn says. Based on the potential for massive fines, which we’ve already seen above, that’s a big understatement. Fortunately, Linn adds, “if there are data breaches, there are certain things you can do to minimize the size of the fine imposed on your company.” These include things like demonstrating that you’re using the most up to date security measures and have extensive documentation outlining the use of your API, whether or not an organization is a first-time offender and how you handle the reporting of the breach. With such a large volume of reported cases, and an unspecified number going unreported, it may be sensible to think along the lines of “when” a data breach happens, not “if”. GDPR Is the Beginning, Not the End Since its introduction, GDPR appears to have inspired laws and regulations in other countries including Chile, Japan, and Brazil. Notably, others claim to have spotted its influence in the California Consumer Privacy Act, which took effect at the beginning of 2020. If California’s adoption of legislation similar to GDPR is anything to go by, the days of US companies being able to bury their heads in the sand appear to be numbered. So what steps can be taken to get prepared for the spread of GDPR-esque regulations? Linn suggests the following: Organizational and technical security measures Education for employees – which might start off as simply as explaining how to use bcc instead of cc – on minimizing risk of and identifying data breaches Have a plan in place to deal with a data breach – risk assessment, corrective measures, documenting decisions, etc. Documentation and internal audits, e.g. logging systems at or above the database level Data minimization – limit the scope of a personal data breach by deleting personal data, say every 3 years, rather than keep decades worth of data With regards to data minimization and APIs, it’s smart to expose only the information that you NEED to expose to authenticated/authorized parties. Close endpoints by default with delegation based on OAuth scopes to match identity. We’ve previously written about how OAuth is your best friend when it comes to protecting your API with financial grade security. For APIs specifically, we know that a huge volume of sensitive information is being passed between applications on a daily basis. Balancing the public nature of APIs with data sharing is tricky. But let’s not forget the example of Marriott cited above; it isn’t just your own API(s) that you need to be thinking about when it comes to GDPR compliance. You need to make sure that the services you’re integrating with are compliant as well. If you can’t be sure that’s the case, you might want to think about whether or not your business could afford the fines cited above before you decide to do business with them.