Skip to content

Comment on Web Security is Too Hard

Comments

This isn't a secfail. Why is pay.cloudflare.com so hard to establish? Why does marketing always get to overpower engineering? I expect Cloudflare services to avoid some sketchy .pay TLD for exactly the reasons this person went through.

Why is pay.cloudflare.com so hard to establish?

An engineer who vibes up a marketing site, and attempts to put it on the same origin as *.cloudflare.com now has to jump through 1,000 hoops of security clearance, customer notifications, etc.

`pay.cloudflare.com` can't be launched because it doesn't have the proper WAF preventing 25 year old Wordpress exploits, please make sure pay.cloudflare.com/wp-admin.php is blocked. I don't care that it's a Zig application.

I remember just doing SOC2 for a startup and it made just spinning up an EC2 instance require several steps of rigamarole just to be "in-compliance". And if anything goes wrong? Well why didn't you follow the 2,000 step process?

I don't envy anyone who has to deal with issues like these.

Probably half those problems are SOP/CORS, which gets in the way in exchange for a false sense of security. I'm on board with ditching that. Websockets already did. (Cookies should still adhere to SOP though.)

Presumably the big scary sysadmins have access to the *.cloudflare.com DNS records, and marketing just needs to push this thing right now and can't wait, so it's easier for them to buy a new domain with a shiny new TLD than wait for pay.cloudflare.com to be authorised.

cloudflare.com/pay probably has a similar chain of approval: if every marketing idea had its own top-level route, it would get pretty crazy with such a big company.

Google manages it though. And you could have a labs.cloudflare.com/idea and make it easy to add new ideas internally.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.