Public Function URL returning a 403 Forbidden

Question

I am using AWS Lambda Function URLs behind an application proxy (traefik) to serve as my app's API. For testing, I have made my function url's public, using the default Auth Type NONE. I am successfully able to invoke my lambdas via the public function urls within my application code, Postman, cURL etc. However, within my application proxy running in ECS proxied requests to the function urls return to me a 403 Forbidden, with the header X-Amzn-Errortype: AccessDeniedException and the lambdas not invoked at all. I spun up my application proxy in a local docker container and from there proxied local requests to the public function urls and to my surprise they failed there too, with the exact same 403.

I'm concluding that it must be the proxy transforming the request in a manner that AWS Lambda is not happy with but I'm still at a loss as to what could cause a publicly available function url, with the Auth Type set to NONE, to return a 403? The lambda is not invoked at all but I know the request reaches AWS because I get back a 403 with an X-Amzn-RequestId & X-Amzn-Errortype.

Note: My lambda has no business logic in which a 403 could be returned.

I'm concluding that it must be the proxy transforming the request in a manner that AWS Lambda is not happy with but I'm still at a loss as to **what could cause a publicly available function url, with the Auth Type set to NONE, to return a 403?** The lambda is not invoked at all but I know the request reaches AWS because I get back a 403 with an X-Amzn-RequestId & X-Amzn-Errortype.

Note: My lambda has no business logic in which a 403 could be returned.

Karanbir_c · Accepted Answer

The 403 Forbidden error with X-Amzn-Errortype: AccessDeniedException, while working with direct invocations but failing through a proxy, suggests a request transformation issue.

There are two critical aspects of Lambda Function URL requests that must be preserved:
  1. The Host header in the HTTP request must match the function URL's hostname. This is a fundamental requirement for AWS to properly route and validate the request.
  2. Lambda Function URLs use the API Gateway payload v2 format for request and response payloads. The payload structure must be maintained for successful invocation.

To debug this:
  1. Compare the headers between your successful direct calls and failing proxied calls
  2. Verify that the request payload structure remains intact through the proxy
  3. Check if any AWS-specific headers are being inadvertently added or modified
  4. Check URL Encoding: Ensure that Traefik is not double-encoding or decoding URL parameters.

Since your direct calls work but proxied ones don't, focusing on these request integrity aspects should help identify where the proxy transformation is causing the 403 error.

re:Post Agent · Answer

The issue you're experiencing with your Lambda function URL returning a 403 Forbidden error, despite being set to public access with Auth Type NONE, could be related to a few factors:

1. Resource-based policy: Even if your function URL is set to NONE auth type, the function's resource-based policy must explicitly grant the lambda:invokeFunctionUrl permission. If this permission is not granted, users will receive a 403 Forbidden error when trying to invoke the function URL, regardless of the auth type setting.

2. AWS Config rule: There might be an AWS Config rule in place called "lambda-function-public-access-prohibited" which checks if the Lambda function policy prohibits public access. If this rule is active in your account, it could be preventing public access to your function.

3. Request transformation: As you've mentioned, the proxy (Traefik) might be transforming the request in a way that's causing AWS Lambda to reject it. This could include modifying headers or the request structure in a way that Lambda interprets as unauthorized.

4. CloudFront Origin Access Control (OAC): If you're using CloudFront with your Lambda function URL, make sure you've correctly configured the Origin Access Control. Incorrect OAC configuration can lead to 403 errors when trying to access the Lambda function URL directly.

To troubleshoot this issue:

1. Double-check your Lambda function's resource-based policy to ensure it explicitly grants the lambda:invokeFunctionUrl permission.
2. Verify if there are any AWS Config rules or account-level restrictions preventing public access to Lambda functions.
3. Compare the raw requests sent directly to the function URL with those sent through your proxy to identify any differences that might be causing the authorization failure.
4. If you're using CloudFront, ensure your OAC and function policy are correctly configured to allow access from your CloudFront distribution.

If none of these solve the issue, you may need to open a case with AWS Support under "Account and billing" to check if there are any account-level restrictions causing this behavior.  
**Sources**  
[Control access to Lambda function URLs - AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html)  
[lambda-function-public-access-prohibited - AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/lambda-function-public-access-prohibited.html)  
[Secure your Lambda function URLs using Amazon CloudFront origin access control | Networking & Content Delivery](https://aws.amazon.com/blogs/networking-and-content-delivery/secure-your-lambda-function-urls-using-amazon-cloudfront-origin-access-control/)  
[The Lambdas is not working | AWS re:Post](https://repost.aws/questions/QUOR1_-vzAQ6iBWRx56i2UHw/the-lambdas-is-not-working)

Public Function URL returning a 403 Forbidden

Add your answer

Relevant content