# Ensure Lambda Function URL CORS Does Not Allow Wildcard Origins (*)

- Source: https://support.icompaas.com/support/solutions/articles/a_1788890022825579-ensure-lambda-function-url-cors-does-not-allow-wildcard-origins
- 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 with Cross-Origin Resource Sharing (CORS) configured do not use a wildcard (\*) for AllowOrigins, which permits any website on the internet to make cross-origin requests to the function URL from a browser.

**Rationale**

Configuring AllowOrigins as a wildcard allows any web page, including malicious ones, to issue browser-based cross-origin requests to the Lambda function URL, which can facilitate data exfiltration, cross-site request forgery style abuse, or unauthorized use of the function's functionality from an untrusted origin, particularly when combined with AllowCredentials or a public (AuthType: NONE) function URL. Restricting AllowOrigins to a specific, known list of trusted domains ensures only intended web applications can make cross-origin calls.

**Impact**

-   Prevents arbitrary, untrusted websites from making cross-origin browser requests to the function URL
    
-   Reduces the risk of data exfiltration or abuse via a malicious third-party site
    
-   Requires maintaining an explicit list of trusted origins as new legitimate client applications are added
    

**Default Value**

CORS is not configured by default when a Lambda function URL is created via the API/CLI; if configured via the console with the CORS option selected, it may default to allowing all origins unless explicitly restricted.

**Pre-Requisites**

-   A documented list of trusted origins (domains) that legitimately need to call the function URL from a browser
    
-   IAM permissions to update the function URL configuration (lambda:UpdateFunctionUrlConfig)
    

**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 CORS configuration.
    
5.  Verify that Allow origin does not contain a wildcard (\*), and instead lists specific, approved domains.
    
6.  If a wildcard origin is configured, 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.  Under Configure cross-origin resource sharing (CORS), remove the wildcard (\*) entry from Allow origin.
    
5.  Add each specific, trusted origin domain (for example, https://app.example.com) individually.
    
6.  Save the changes.
    
7.  Test from an approved origin to confirm requests still succeed, and from a non-approved origin to confirm the browser now blocks the cross-origin request.
    

**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.  Add the wildcard (\*) back to Allow origin.
    
5.  Save the changes.
    

**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)

## 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.