AWS’s latest announcement will accelerate the already explosive growth of APIs

AWS recently announced AWS Lambda Function URLs which provide built-in HTTPS Endpoints for Single-Function Microservices. Continuing its strategy of “Primitives, not frameworks,” as repeated by Amazon CTO Werner Vogels during AWS re:Invent last year, AWS prefers offering customers a collection of primitives and tools. This allows developers to pick and choose their preferred way to interact with AWS instead of providing one single framework that they are forced to use, which includes everything and the kitchen sink.

Previously each AWS Lambda function would be mapped to API endpoints, methods, and resources using services such as Amazon API Gateway and Application Load Balancer. Amazon API Gateway is a managed service that allows developers to create, publish, maintain, monitor, and secure APIs. With API Gateway, companies can access features such as:

• Authentication and authorization
• Request throttling (in addition to basic request throttling in Lambda)
• API Lifecycle management
• Request and response mapping
• Websocket APIs (two-way communication between client apps and their backend)
• Private integrations with AWS ELB

These features come at a cost, however, so the intended usage and profile of the production application should help you decide one approach over the other.

With the recently announced Lambda Function URLs, you can create REST APIs backed by Lambda functions without the need for an API Gateway. AWS Lambda function URLs are meant as a simple way to configure an HTTPS endpoint in front of your function without having to learn, configure, and operate additional services besides Lambda itself, for example if you just wanted to create an internal API authorized via IAM. One of the main benefits being AWS will take care of making this service highly available, scalable, and secure. For simple APIs that don’t need advanced API Gateway features, you now have the option to save on your AWS costs and use Lambda function URLs instead.

These changes will make it a lot more straightforward to expose your functions as HTTPS endpoints, but there are tradeoffs. Faster developer velocity will be a very positive outcome of this, but it could very well contribute to an unchecked rise of the overall number of APIs in your organization and create new security risks.

Example: Creating a new Lamda function URL in AWS Console

When creating a new Lambda function you can now see the option to Enable function URL in advanced settings:

To secure your function URL, you can choose between IAM authorization (AWS_IAM) or no authorization (NONE). If you decide not to use IAM authorization, you should implement your own authorization logic in your function. Function URLs support JSON Web Token (JWT), OpenID Connect (OIDC), and OAuth2 authentication methods.

To control access to your function URL from other origins, you can also configure Cross-Origin Resource Sharing (CORS) which is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a client should permit loading resources.

Why This Matters: Digital Transformation Requires Developer Velocity

We continue to see this trend accelerating: more and more APIs are put into production as we keep driving digital transformation on a global scale, and policy directives like Open Banking are forcing even more traditional organizations to adopt this new reality.

From a security perspective, we now also have to deal with this different approach and ask ourselves, if it becomes this easy to expose services since it is just as easy to build public APIs using this new functionality, can we keep an up-to-date inventory and apply governance across the board?

Questions like these matter because, today, everything is an attack surface. For example, another piece of news that arrived just a few days ago was the discovery of the first malware targeting AWS Lambda dubbed “Denonia,” proving that whilst AWS Lambda might be secure by default, bad actors will keep coming up with innovative ways to abuse these types of services. If security teams don’t have an accurate inventory to know what to secure, this creates more risk for the company.

API Stakeholders

The reality is that besides developers there are many stakeholders when it comes to delivering API services and doing so securely.

• Product owners of the new services
• Network Admins connecting the system into existing environments
• InfoSec and AppSec professionals applying security controls
• Security Operations (SOC/IR) handling day-to-day operational security
• Mobile Teams providing mobile app functionality
• Cloud Teams providing cloud cost and governance controls
• And many more…

It all starts with visibility and awareness. We need to be able to answer the seemingly straightforward question, “How many, and what types of APIs do I have?” before we can start to apply security and governance controls. At Noname Security, we aim for a holistic approach to API security and focus on three pillars to provide end-to-end security, namely:

1. Posture Management

With an emphasis on de-risking your environment we show you where your APIs are, what they are doing and what type of (sensitive-) data they are handling, how they are configured and if they adhere to the specifications your organization has set out beforehand.

2. Runtime Protection

Looking at API transactions in real-time and determining if they are operating as expected or if we can detect any misbehavior, for example, an attacker trying to abuse your APIs. We do this by leveraging machine learning (ML) models to establish a baseline of normal behavior and then detect any deviations from the baseline and show you anomalous activity to take action upon.

3. API Security Testing

When you introduce a new API service or update an existing one, you want to make sure that you are not introducing any vulnerabilities into your environment. We help organizations “shift left” and bring API security awareness as early as possible into the development lifecycle, not by forcing developers to adopt yet another tool but by smoothly integrating into their existing build pipelines and CI/CD practices.

By adhering to this comprehensive approach to API security, you should be able to confidently build and publish new API-powered services and accelerate your digital transformation.