Public API Gateway with no authorizer
A REST API wired to Lambda, wide open, with no access logging.
Press Run. The stack loaded here fails in a way worth seeing.
▸What the engine finds8 findings
Not examples — Public API Gateway with no authorizer was run through the real engine when this page was built, and this is what it returned.
AuthorizationType is NONE — anyone on the internet can call this API.INTENT
▸ 7 informational findings — no access logging, request validation is, stage has no
No access logging on the stageAwsSolutions-APIG1DeploymentStage.prod
The API does not have access logging enabled. Enabling access logs helps operators view who accessed an API and how the caller accessed the API.
Full rule text
The API does not have access logging enabled. Enabling access logs helps operators view who accessed an API and how the caller accessed the API.
Request validation is offAwsSolutions-APIG2Api
The REST API does not have request validation enabled. The API should have basic request validation enabled. If the API is integrated with custom source (Lambda, ECS, etc..) in the backend, deeper input validation should be considered for implementation.
Full rule text
The REST API does not have request validation enabled. The API should have basic request validation enabled. If the API is integrated with custom source (Lambda, ECS, etc..) in the backend, deeper input validation should be considered for implementation.
Stage has no WAFAwsSolutions-APIG3DeploymentStage.prod
The REST API stage is not associated with AWS WAFv2 web ACL. AWS WAFv2 is a web application firewall that helps protect web applications and APIs from attacks by allowing configured rules to allow, block, or monitor (count) web requests based on customizable rules and conditions that are defined.
Full rule text
The REST API stage is not associated with AWS WAFv2 web ACL. AWS WAFv2 is a web application firewall that helps protect web applications and APIs from attacks by allowing configured rules to allow, block, or monitor (count) web requests based on customizable rules and conditions that are defined.
Methods have no authorizerAwsSolutions-APIG4ANY
Every method on this API can be called by anyone who finds the URL. There is no authorizer in front of it.
Full rule text
The API does not implement authorization. In most cases an API needs to have an authentication and authorization implementation strategy. This includes using such approaches as IAM, Cognito User Pools, Custom authorizer, etc. AwsSolutions-APIG4 guide →
No CloudWatch logging on methodsAwsSolutions-APIG6DeploymentStage.prod
The REST API Stage does not have CloudWatch logging enabled for all methods. Enabling CloudWatch logs at the stage level helps operators to track and analyze execution behavior at the API stage level.
Full rule text
The REST API Stage does not have CloudWatch logging enabled for all methods. Enabling CloudWatch logs at the stage level helps operators to track and analyze execution behavior at the API stage level.
Not using a Cognito authorizerAwsSolutions-COG4ANY
The API GW method does not use a Cognito user pool authorizer. API Gateway validates the tokens from a successful user pool authentication, and uses them to grant your users access to resources including Lambda functions, or your own API.
Full rule text
The API GW method does not use a Cognito user pool authorizer. API Gateway validates the tokens from a successful user pool authentication, and uses them to grant your users access to resources including Lambda functions, or your own API.
Uses an AWS-managed policyAwsSolutions-IAM4
AWS-managed policies are written to fit everyone, so they grant far more than your code uses. Their scope also changes when AWS updates them, without you deploying anything.
Full rule text
The IAM user, role, or group uses AWS managed policies. An AWS managed policy is a standalone policy that is created and administered by AWS. Currently, many AWS managed policies do not restrict resource scope. Replace AWS managed policies with system specific (customer) managed policies.This is a granular rule that returns individual findings that can be suppressed with 'appliesTo'. The findings are in the format 'Policy::<policy>' for AWS managed policies. Example: appliesTo: ['Policy::arn:<AWS::Partition>:iam::aws:policy/foo']. (construct: ServiceRole · Policy::arn:<AWS::Partition>:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole) — Avoid AWS managed policies AwsSolutions-IAM4 guide →
Or start from a stack that fails interestingly
The single most common AI-generated CDK mistake: a bucket left open to the world.
SSH open to the entire internet — the classic copy-paste ingress rule.
Website hosting straight off a bucket — no CDN, no TLS, no access logging.
A database with storage encryption off and backups barely configured.
Action "*" on Resource "*" — the permission grant that ends incident reviews.
A REST API wired to Lambda, wide open, with no access logging.
Fast to write, impossible to restore — no PITR, no encryption choice.
A CDN that will happily serve your site unencrypted, with no logging.
A queue with no server-side encryption and no dead-letter queue.
Network traffic no one can reconstruct after the fact.
Six characters, no symbols, no MFA — defaults nobody revisited.
The one that passes. Encrypted, recoverable, with a dead-letter queue — what good looks like.