Repository navigation
sec(iac): production Lambda Function URL uses authorization_type=NONE — no IAM gate #424
Description
Files:
terraform/modules/compute/aws/lambda/variables.tflines 94-96 (defaultfunction_url_auth_type = "NONE")terraform/environments/aws/github-prod.tfvarsline 27:lambda_function_url_auth_type = "NONE"(line 28 also haslambda_allowed_origins = ["*"]with a TODO)terraform/environments/aws/github-dev.tfvarsline 27-28: sameterraform/modules/compute/aws/lambda/main.tflines 130-137 grantsprincipal = "*"whenauth_type == "NONE"
The Lambda Function URL in production is publicly invokable with no AWS IAM check — the application's own auth layer is the only gate. Any unauthenticated network request reaches the Lambda handler. The allowed_origins = ["*"] in prod amplifies exposure (cross-references #390 for the CORS variant).
The CloudFormation template cloudformation/stacks/CUDly/template.yaml is structured better — uses AuthType: AWS_IAM with a CloudFront OAC, gating the Function URL behind CloudFront. The Terraform-managed deployment does not replicate this.
Fix: Either set lambda_function_url_auth_type = "AWS_IAM" and front Lambda with CloudFront OAC, or document the application-layer mitigations that replace IAM auth. Also resolve the TODO on lambda_allowed_origins in github-prod.tfvars.
Activity
cristim commentedon May 19, 2026
PR #519 (CORS hardening) initially listed this issue under
closesbut the CORS fix is a separate concern. This issue still tracks the Function URLauthorization_type=NONE→AWS_IAMswitch + the matching IAM grant + frontend signing changes.sec(iac): reject wildcard CORS origin, set explicit origins per env (c…
sec(iac): add AWS_IAM Function URL auth + CloudFront OAC scaffolding (#…
sec(iac): add AWS_IAM Function URL auth + CloudFront OAC scaffolding (#…
refactor(iac): derive lambda_function_url_auth_type from enable_cdn (…
sec(iac): add AWS_IAM Function URL auth + CloudFront OAC scaffolding (#…
refactor(iac): derive lambda_function_url_auth_type from enable_cdn (…
sec(iac): Lambda Function URL auth hardening -- CORS wildcard rejecti…
cristim commentedon May 28, 2026
Verification: cannot-verify-autopilot. PR #519 (CORS wildcard rejection, merged 2026-05-20) and PR #574 (OAC scaffolding, merged 2026-05-28) are both in
feat/multicloud-web-frontend. However, PR #574 explicitly keeps all three tfvar environments atauthorization_type=NONEwith TODO cut-over comments untilenable_cdn=trueis set: 'All three env tfvars keep NONE with a TODO(#424) cut-over comment until enable_cdn = true is set and CloudFront is deployed.' Live Lambda URL athttps://33pz7pombdqwu3bdlxp4lqxyra0bsriy.lambda-url.us-east-1.on.aws/healthreturns HTTP 200 without IAM signing, confirming auth_type=NONE is still in effect. The structural fix (OAC + auth_type derivation) is merged but the production environment has not been switched. Leaving open pendingenable_cdn=truedeployment.