API Attacks: What Are They and How Can Universities Prepare?

But with powerful APIs come serious risks. APIs are direct pathways to the internals of applications. They are usually developed assuming that only friendly and authorized developers will be using them, and they often short-circuit normal access controls or other security features. In the hands of a malicious actor, a poorly designed API may allow for massive levels of data exfiltration, unauthorized updates and improper viewing of sensitive data.

In the world of cloud computing, APIs present additional risks, with data flying between data centers, subject to monitoring and man-in-the-middle attacks.  Securing APIs can be a delicate balancing act, with developers insisting on a minimum of requirements and lowest overhead while security teams want heavyweight protections.  Here are five guidelines for keeping APIs useful and secure in higher education environments.

RELATED: Higher education institutions can create a seamless learning experience.

1. Require Authentication and Implement Strong Authorization Access Controls

Every API must use authentication, preferably based on standards such as SAML or OAuth (depending on the authentication model) for all queries. Once authenticated, the API should have a robust role-based access control system to ensure that users don’t see data beyond their level of authorization. An API shouldn’t talk to anyone without knowing who they are, even if the developer is sure that the data affected is nonsensitive or public information.

Why protect public data? Two reasons: first, just because data is public doesn’t mean that it’s in the interest of the university to have the entire database exported by a third party and lose control of the information. Second, APIs can have bugs in them. By requiring anyone using the API to be authenticated and authorized, you reduce the risk of unintended consequences from opening things up.

Authorization can be tricky with APIs because an API is program-to-program communication. This means that the application providing the API doesn’t obviously know who it is that is requesting data. Implementing authorization can take several paths. It may mean using OAuth 2.0’s On-Behalf-Of flows, which pass access tokens to the APIs or by simply passing the user information in the API call. These let the receiving API can make its own authorization decisions. Alternatively, some type of centralized policy enforcement tool, filter or a dedicated authorization microservice can be used to help APIs return only authorized results.

Even in cases where an API is published on the internet for anyone to use, it’s desirable to have an additional offline step that mandates anyone who wants to use it to register and agree to an acceptable use policy first. This requirement can rub some people the wrong way in a higher ed environment, but it’s always a question of balancing security and privacy against open access. Making an initial bid for more security helps protect not only the institution but also the student, faculty and research data you may be delivering via API.

Finally, if your developers are using API keys for authentication between services, make sure that these aren’t hard coded in source code or Git repositories, that they have a finite life, can be revoked if compromised and are rotated at least annually. For larger services, require that different API keys are used for different environments, such as development, test and production.

Click the banner for more security insights from leaders throughout higher education.

2. Require Encryption Using HTTP/S

All API calls should be run over an encrypted tunnel, typically using HTTP/S (HTTP over TLS/SSL). This protects the data in transit and blocks most man-in-the-middle attacks. Early API adopters in higher education may have APIs that don’t require encryption: in-house developers may have thought that the on-campus network was secure, or that the overhead of encryption was going to slow things down. IT administrators should track down any unencrypted legacy APIs and insist on adding an encryption layer.

The unanticipated consequences of a shift to cloud computing make this even more urgent. API communications that originally may not have left a single rack in the university data center now can travel between different data centers across the open internet, without anyone thinking to check with the owner of the API.

As we’ve seen with recent attacks such as Salt Typhoon, carrier networks that were previously thought to be secure and untappable have been breached and data exfiltrated. A university with a direct link to a Tier 1 ISP connecting to a cloud data center can no longer assume that its traffic is secure against monitoring or modification.

3. Shut Down or Place Guardrails on Shadow IT APIs

Some of the biggest API breaches have come from developers who have used cloud-based services for temporary deployments or for testing. Unprotected databases and storage buckets give attackers the ability to siphon off every bit of data at multigigabit speeds. IT managers won’t make friends with a heavy-handed approach, but they still should insist on a strict policy that any API in any data center be secure from the first instantiation.

It’s best to have full authentication and authorization, but a compromise approach based on IP access lists and some simple username/password authentication can be acceptable for low-risk APIs without sensitive data behind them.  Even so, it’s on the IT manager’s plate to ensure that a short-term test project doesn’t turn into a permanent API just because no one makes the effort to shut it down or secure it.

GO DEEPER: Reducing the “blast radius” of breaches with a zero-trust strategy.

4. Make Higher Education APIs Self-Protective

The tendency in programmers is to assume that other developers are well-behaved, but that’s just not true, especially when attackers using APIs easily masquerade as legitimate applications. This means that APIs must be self-protective. They should validate all inputs. This is easier in the world of XML than it used to be, so pushing developers to use JSON or XML in their APIs can help where performance allows it, and sanitize them against possible attacks such as SQL and command or shell injection.

APIs should also implement rate limiting and request throttling. This helps not only with attackers trying to dump an entire data set but also with attackers who might be launching a Denial of Service attack.  Rate limits can be tied to authorization or API keys to exempt or extend limits for trusted and privileged app-to-app communications.

5. Link APIs to Other Security Infrastructure

Because APIs are where programs meet other programs, traditional in-application error handling and logging isn’t always appropriate. When an API is called, that’s not all that different from security point of view from any web application: Someone, very possibly an attacker, is trying to connect to your infrastructure and extract or modify data. This means that API logging has security implications and should flow accordingly.

Different campuses have different security tools, but all APIs should log both success and errors to some sort of central service (not individual local log files), and some of that information should continue to flow to the campus security tools, such as security information and event management solutions. Once the information is accessible, traditional security anomaly detection tools and break-in detection analyzers can do their work and proactively identify attacks and possible flaws.

APIs in higher education have the potential to deliver better applications and more powerful tools. IT managers must properly secure and monitor their use to ensure that they don’t become a doorway for attackers.