# Ensure Lambda Function URL is Not Publicly Accessible

- Source: https://support.icompaas.com/support/solutions/articles/a_1788890023235739-ensure-lambda-function-url-is-not-publicly-accessible
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS Cloud](https://support.icompaas.com/support/solutions/c_1788889426924716) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1788889470630116)
- Last updated: 2026-09-08
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that Lambda function URLs do not have AuthType set to NONE with a resource-based policy that allows the wildcard principal (\*), which permits any unauthenticated caller on the internet to invoke the function directly.

**Rationale**

When a function URL's AuthType is NONE and a resource policy grants invoke permission to Principal '\*' (the FunctionURLAllowPublicAccess statement typically added when NONE is selected via the console), any unauthenticated party who discovers the URL can invoke the function, potentially triggering unintended business logic, consuming compute resources, driving up cost, or accessing data returned by the function. Unless a function URL is genuinely intended to serve as a public, unauthenticated endpoint, invocation should require AWS\_IAM authentication or be restricted to specific principals.

**Impact**

-   Prevents unauthenticated internet callers from invoking sensitive or internal functions via their URL
    
-   Reduces the risk of resource abuse, unexpected billing, or unintended business logic execution
    
-   Requires clients to be updated with proper IAM credentials if switching a previously public URL to AWS\_IAM auth
    

**Default Value**

Function URLs are not created by default; when created via the console with Auth type NONE, a public-access resource policy is automatically added unless explicitly restricted.

**Pre-Requisites**

-   IAM permissions to view and update the function URL configuration and resource policy (lambda:GetFunctionUrlConfig, lambda:UpdateFunctionUrlConfig, lambda:RemovePermission, lambda:AddPermission)
    

**Test Plan**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Navigate to AWS Lambda and select the function to review.
    
3.  Open the Configuration tab, then Function URL.
    
4.  Review the Auth type field.
    
5.  If Auth type is NONE, open the Permissions tab and review the resource-based policy for a statement granting lambda:InvokeFunctionUrl to Principal '\*'.
    
6.  If such a statement exists on a function that should not be public, follow the implementation steps.
    

**Implementation Steps**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Navigate to AWS Lambda and select the function to update.
    
3.  Open the Configuration tab, then Function URL, and select Edit.
    
4.  Change Auth type from NONE to AWS\_IAM.
    
5.  Save the changes.
    
6.  Navigate to the Permissions tab and remove any remaining resource-based policy statement (such as FunctionURLAllowPublicAccess) granting access to Principal '\*', since it is not automatically removed when the auth type changes.
    
7.  Grant invoke permission (lambda:InvokeFunctionUrl) only to the specific IAM roles or users that legitimately need to call the function, and update client applications to sign requests using SigV4.
    

**Backout Plan**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Navigate to AWS Lambda and select the affected function.
    
3.  Open the Configuration tab, then Function URL, and select Edit.
    
4.  Change Auth type from AWS\_IAM back to NONE.
    
5.  Save the changes, then add a resource-based policy statement granting lambda:InvokeFunctionUrl to Principal '\*' if public access should be restored.
    

**Reference**

-   [https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.