S3 static website
Website hosting straight off a bucket — no CDN, no TLS, no access logging.
Press Run. The stack loaded here fails in a way worth seeing.
▸What the engine finds5 findings
Not examples — S3 static website was run through the real engine when this page was built, and this is what it returned.
A public website with no access logs cannot be audited after an incident.INTENT
▸ 4 informational findings — bucket serves a, no server access, requests not forced
Bucket serves a website index documentINTENT
No server access logsAwsSolutions-S1Site
Without server access logs there is no record of who read what. After an incident that is the difference between knowing what leaked and guessing.
Full rule text
The S3 Bucket has server access logs disabled. The bucket should have server access logging enabled to provide detailed records for the requests that are made to the bucket. AwsSolutions-S1 guide →
Requests not forced onto HTTPSAwsSolutions-S10Site
Requests can arrive over plain HTTP, so object contents and any credentials in the request travel unencrypted across the network.
Full rule text
The S3 Bucket or bucket policy does not require requests to use SSL. You can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition on Amazon S3 bucket policies. AwsSolutions-S10 guide →
CDN origin reachable directlyAwsSolutions-S5Site
The CloudFront origin can be reached directly, so the CDN can be bypassed entirely — along with anything it was enforcing.
Full rule text
The S3 static website bucket either has an open world bucket policy or does not use a CloudFront Origin Access Identity (OAI) in the bucket policy for limited getObject and/or putObject permissions. An OAI allows you to provide access to content in your S3 static website bucket through CloudFront URLs without enabling public access through an open bucket policy, disabling S3 Block Public Access settings, and/or through object ACLs.
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.