# Ensure Lambda function URL CORS does not allow wildcard origins (*)

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292233428601-ensure-lambda-function-url-cors-does-not-allow-wildcard-origins
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that the cross-origin resource sharing (CORS) configuration of every AWS Lambda function URL does not include the wildcard \* in its allowed origins. Allowed origins should list only the specific trusted websites that need to call the function from a browser.

**Rationale**

A wildcard origin lets any website call the function URL from a visitor's browser and read the response. This weakens browser origin isolation and can expose data to malicious sites, or let them trigger state-changing actions if the function accepts them. Restricting allowed origins to trusted domains, and keeping allowed methods and headers to the minimum needed, applies least privilege to browser access.

**Impact**

-   Prevents untrusted websites from reading responses from the function URL in a browser
    
-   Reduces the risk of cross-origin abuse of the function
    
-   Browser-based clients served from origins not in the allowed list will receive CORS errors
    
-   Non-browser clients (for example, server-side scripts) are not affected by CORS settings
    

**Default Value**

A function URL has no CORS configuration unless one is added. The console offers a CORS option when the URL is created or edited, and any allowed origins, including \*, must be set explicitly.

**Pre-Requisites**

-   IAM permissions: lambda:ListFunctions, lambda:GetFunctionUrlConfig and lambda:UpdateFunctionUrlConfig
    
-   A list of the exact origins (scheme and domain, for example https://www.example.com) that legitimately call the function from a browser
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the AWS Lambda console and select **Functions**.
    
3.  Select a function and open the **Configuration** tab, then **Function URL**.
    
4.  If a function URL exists, check the **Allow origin** value in the CORS settings.
    
5.  Repeat for each function in each region in use.
    
6.  If any function URL allows the origin \*, follow the implementation steps.
    

**CLI:**

List the functions in a region:

aws lambda list-functions --region <REGION> --query "Functions\[\].FunctionName"

Show the authentication type and CORS allowed origins of a function URL:

aws lambda get-function-url-config --function-name <FUNCTION\_NAME> --region <REGION> --query "\[FunctionUrl,AuthType,Cors.AllowOrigins\]"

A function fails if it has a function URL and AllowOrigins contains \*. Functions without a function URL (the command returns ResourceNotFoundException) are not evaluated.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the AWS Lambda console and select **Functions**.
    
3.  Select the function and open **Configuration**, then **Function URL**.
    
4.  Choose **Edit**.
    
5.  In the CORS settings, remove \* from **Allow origin** and enter each trusted origin, for example https://www.example.com.
    
6.  Choose **Save**.
    
7.  Repeat for each affected function in each region in use.
    

**CLI:**

Restrict the allowed origins to a trusted origin:

aws lambda update-function-url-config --function-name <FUNCTION\_NAME> --region <REGION> --cors AllowOrigins=<TRUSTED\_ORIGIN>

The --cors option replaces the whole CORS configuration, so include any other CORS settings that must be kept (for example AllowMethods, AllowHeaders and AllowCredentials) from the Test Plan output:

aws lambda update-function-url-config --function-name <FUNCTION\_NAME> --region <REGION> --cors "AllowOrigins=<TRUSTED\_ORIGIN>,AllowMethods=GET,POST,AllowHeaders=content-type"

**Backout Plan**

Before making changes, save the current function URL configuration:

aws lambda get-function-url-config --function-name <FUNCTION\_NAME> --region <REGION> > function-url-config-backup.json

To roll back:

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the AWS Lambda console, select the function and open **Configuration**, then **Function URL**.
    
3.  Choose **Edit** and set the CORS settings back to the values in the saved backup.
    
4.  Choose **Save**.
    

Note: rolling back allows any website to call the function URL from a browser again. Use it only as a temporary measure.

**Reference**

-   [https://docs.aws.amazon.com/lambda/latest/dg/urls-configuration.html](https://docs.aws.amazon.com/lambda/latest/dg/urls-configuration.html)
    
-   [https://docs.aws.amazon.com/lambda/latest/api/API\_Cors.html](https://docs.aws.amazon.com/lambda/latest/api/API_Cors.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/lambda/update-function-url-config.html](https://docs.aws.amazon.com/cli/latest/reference/lambda/update-function-url-config.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.