Why APIs Could Be Your Weakest Security Link, and How to Protect Them

Application programming interfaces hold scalable websites together, and a modern digital business cannot run without them. Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, compares them to connective tissue, and points out that a weakness in those joints can cause serious damage, in some cases the kind a business does not survive. His piece sets out the practices that he and a Synopsys colleague recommend for shoring them up.

Misconfigured APIs are common, and attackers know it

Mackey's first example is the exposure of data from Microsoft Power Apps portals that had been configured to allow public access. Researchers at UpGuard found that what leaked differed from portal to portal. It included personal details gathered for COVID-19 contact tracing and for COVID-19 vaccination appointments, Social Security numbers belonging to job applicants, employee IDs, and millions of names and email addresses.

Those portal operators were far from alone, he writes, since misconfigured APIs, and the attacks drawn to them, turn up more often than most people assume. Salt Security surveyed close to 200 enterprise security officials earlier in the year and found that 94% said their organisation had suffered an API security incident during 2020. The same report found malicious API traffic had grown by 348% in six months, a sign that attackers are concentrating on routes to data.

OWASP recognised the problem at the end of 2019 when it began a dedicated list, the OWASP API Security Top 10, for API weaknesses. Mackey notes that APIs give ready access to whatever data an organisation exposes through them. Some are meant for the public and others only for use inside an application, but in every case an API exists to hand over data directly. For that reason he argues each one needs explicit testing to confirm it does not return more data than it should and cannot be used to get around authorisation. Yet in BSIMM12, where activity ST2.6 covers fuzz testing of APIs, only 12% of organisations were found doing it.

Know what you have, and who is using it

The practical guidance comes from John Tapp, a senior consultant with the Synopsys Software Integrity Group. His starting point is inventory and documentation. Security people often repeat that nobody can protect an asset they do not know exists, and Tapp says the saying has become a cliché because it is accurate, and it describes the state of far too many APIs. He likens the problem to an iceberg, with only about a tenth showing above the water. "A lot of code may not be formally documented in a way either humans or machines can consume, so it may not get tested," he said. His remedy has five parts:

• list the application assets that are built on APIs;
• rank those assets by their level of risk;
• locate the API endpoints each asset exposes;
• follow automated deployments so the inventory stays current;
• use security tools and services to detect problems automatically.

Identity and access management is routine security practice, but Tapp says that with APIs it has to centre on two questions: how a user authenticates to the API, and how the API authorises that user at each point along the way. "Authentication is your ID at the security checkpoint in the airport, while authorisation is the boarding ticket at the gate," he said. There are many ways to implement this, in his view, but the user has to be followed through the whole system, and every function in the application should be built knowing what it must do to confirm who the user is and what they may do.

Validate data, encrypt it and configure the platform

On data trust, Tapp asks how an API checks what it receives from the consumer of the data, whether that input is malformed, and if so how it gets corrected. APIs need input validation just as web applications do, he says. An attacker talking to an API may tamper with the way data is sent, so the API has to know how to handle malformed input. The difference is that validation covers more ground: the parameter values need checking, and so does the schema used to carry the data.

Cryptography should be obvious, the article says, yet it remains essential that data is encrypted securely, both at rest and in transit, wherever that is required. JSON Web Tokens are widely used for authentication and authorisation (AuthN/AuthZ), and because they carry a cryptographic signature, the API has to validate that signature.

Configuration is the next concern. When an API runs in the cloud or in containers, those environments must themselves be configured securely, or the effort spent protecting the API can be weakened or wiped out. Misconfiguration is listed as API7:2019 in the OWASP API Top 10. It covers unpatched systems, unprotected files and directories, images that have not been hardened, TLS that is missing, out of date or misconfigured, exposed storage or server management panels, a missing CORS policy or missing security headers, error messages that reveal stack traces, and features left switched on without need.

Open source code is almost certainly part of the picture as well. Synopsys's 2021 Open Source Security and Risk Analysis Report found open source components in 98% of codebases, making up 75% of those codebases on average. The article recommends a software composition analysis tool to find known vulnerabilities in those components along with possible licensing conflicts.

Watch the traffic and trace it back

The last area is active monitoring and alerting, which Tapp breaks into several parts:

• Content inspection. Scan at the application layer for attempts at SQL injection, and be clear about how incoming API traffic is examined and what happens to it afterwards.
• Bot and attack detection. Put controls around the API, or build them into it, that guard against known attack techniques and against heavily automated attacks run by bots.
• Throttling. Decide how API use will be capped and what happens once a limit is passed.
• Logging. Set up a tactical audit procedure, so that logs are reviewed and alerts are meaningful and deliver what is actually needed.
• Tracing. Being able to follow any negative finding or activity back to where it came from, whether a development team or an application, is especially valuable. Without that ability, the article warns, an organisation is not setting itself up to succeed.