Slaying the Hydra: The Multi-Headed Beast That Is API Security

November 29, 2019 Brian McClain

When do you start discussing security when building a new application? After your first few sprints? Just before release? While this is the reality for many, the answer should be “Day One.” 

And what about your APIs? For something so close and integral to your data, API security is often neglected or overlooked entirely. There are small steps that have an enormous impact on your security that you can take today, and that goes double if you’re a Spring developer.

Designing Your APIs

A secure API begins with how you design it. Of course, there are some age-old best practices that still continue to be true. For example, the principle of least privilege still remains one of the best things you can do for your security, allowing access to only the bare minimum of what your services need to fulfill their purpose. If you’re building a REST API, proper use of the HTTP verbs (GET, POST, PUT, etc.) really allows for granular control when it comes to authorization. 

Also, be conscious about your error messages While you want to inform the developer of what happened, offering too much information can be as good as gold for someone with malicious intent. 

Finally, sanitize your input! Not only that, but be conscious of what you do with that data. SQL injection, command injection, and format exploits are all still common attack vectors, yet many developers still don’t take a fine-tooth comb through their users’ input before processing it.

API design, the first stage of API security, is something I can geek out about for an entire blog on it’s own, but I’m not alone on that one. Some of my peers have shared their thoughts on this in a wonderful four-part blog on the Principles of Designing & Developing an API Product. Additionally, OWASP provides a great REST Security Cheat Sheet of things to keep in mind while building your service.

A Framework With Security in Mind

If API security truly is like battling a hydra, then one of the heads is authentication and authorization. Validating that someone is who they say they are and ensuring they only have access to the resources they’re entitled to, all while locking down the fort from attacks such as spoofing can quickly become a Herculean task. 

Fortunately, managing these concerns can be made extremely simple with the help of Spring Cloud Security. SCS has become the most popular download in the Spring ecosystem just behind the Spring Framework itself, and for good reason. It gives us all the tools we need to authenticate our users and control their permissions. For those who haven’t kicked the tires on it yet, there’s a great quickstart on the Spring website that goes over the simplest scenario. 

If you have your own SSO provider, or are integrating with an external one like GitHub or Google, you’re all set. But for those that don’t, there’s a somewhat lesser-known feature of Spring Cloud Security, and that is that it can act as an SSO provider as well! With a single annotation and a few lines of configuration, you can have an authorization server ready to go and register users.

Of course, Spring is developed with building safe and secure applications in mind, and gives you a lot of tools out of the box to do so, which our friends at Snyk highlight in their great cheat sheet for security and Spring. Your user sessions can be managed by Spring Session. Even some of the fundamentals of web security like CSRF protection are enabled by default. Rarely are you writing raw SQL queries with Spring Boot; instead you are using something like Spring Data.

Speaking of data, let’s take a look at a specific example straight from the OWASP page on SQL injection, and we’ll see how Spring can help us out. You can see the code for this demo on GitHub. First, let’s consider the following SQL query:

select * from products where id=$id

This seems straightforward enough, right? We’re grabbing all of the fields of a product (in this case, the name and price) in a database that matches an ID that’s given to us by the user, perhaps by means of a web frontend. Let’s suppose that’s done by sending the following GET request:

http://localhost:8080/unsafe/<ID>

That’s all well and good. Our site will get one product back and display it to the user. But what if a user decides to take matters into their own hands and crafts the following request on their own?

http://localhost:8080/unsafe/3%20OR%201=1

Removing the URL encoding, we can see that the request is asking for an ID of 3 OR 1=1, which in turn makes the SQL query become the following:

select * from products where id=3 OR 1=1 

For the keen observer, you may notice that suddenly, this request will now return every entry in the database, since OR 1=1 will always evaluate to true. Now, a simple request to get a product is suddenly dumping our entire inventory. That’s bad. But suppose our attacker were querying a table called users, rather than products? Now we’re talking about a complete list of every user on our website, including usernames, emails, or worse.

How does Spring help us here? Well, instead of writing our own queries, we can use Spring Data JPA! In this case, we can define a Product object, and then create a JPA repository for it:

@Repository

public interface ProductRepository extends JpaRepository<Product, Integer> {}

Then, our query becomes:

Optional<Product> p = productRepo.findById(id);

Hold The Gates!

No matter if your APIs are being used by internal services or external developers, a strong API gateway means better control and flexibility for requests to your services. Not only that, but it provides a great point to collect really rich metrics that measure traffic to your APIs (and even better, to catch when something goes sideways). Ben Wilcock and I have been spending quite a bit of time with Spring Cloud Gateway lately, learning the basics, experimenting with service discovery, and of course learning about how it can integrate with Spring Cloud Security.

The real power of Spring Cloud Gateway is its flexibility and how strongly it’s integrated into the entire Spring ecosystem. Service discovery is done the same way you would with any other Spring application. You can use Spring Cloud Security to authenticate and authorize users. You can even easily integrate the circuit breaker pattern using Spring Cloud Services or centralize your configuration using Spring Cloud Config.

A Platform That Enables You

The job of securing your applications is never done, and the same goes for your infrastructure. As attacks mature and research continues, bugs and exploits can be found anywhere in your technology stack. 

Because of this, how you patch the platform is just as important as how you patch your own applications. Waiting  hours or even days to apply that update off-hours to apply that update isn’t an option if that update is to patch, say, Meltdown. With the proper platform, it’s no longer a compromise between uptime and security when patches can be applied automatically with no downtime.

If all of this sounds great to you, what might sound even better is being able to take it for a spin. Pivotal Platform is the best place to run Spring applications, and you can try it for free using Pivotal Web Services, complete with a full marketplace of services including Spring Cloud Services.

Didn’t have a chance to make it to SpringOne Platform? We’ve got you covered with vides of each and every keynote and breakout session. From updates on Spring Cloud Data, to getting hands-on with Spring Security, to discussing how teams should approach security as a whole. There’s plenty of topics for everyone, even if you’re not a Spring developer! 

About the Author

Brian McClain

Brian is a Principal Product Marketing Manager on the Technical Marketing team at Pivotal, with a focus on technical educational content for Pivotal customers as well as the open source communities. Prior to Pivotal, Brian worked on both the development and operations of software, with a heavy focus on Cloud Foundry and BOSH at companies in many industries including finance, entertainment and technology. He loves learning and experimenting with new technologies, and more importantly sharing the lessons learned along the way

Follow on Twitter Follow on Linkedin More Content by Brian McClain
Previous
Episode 159: A Checklist for API Security with Wim Remes
Episode 159: A Checklist for API Security with Wim Remes

As a security expert and consultant, Wim Remes (@WimRemes), was fed up with clients using security products...

No More Articles