[wesleyac]

Hey! I'm the person who made this — I don't believe there's an actual problem here, since login cookies are set on the top-level domain (and thus are inaccessible to content on subdomains), and are HTTPOnly as well.

I do notice that Stripe sets a tracking cookie (which only happens for people who pay for the service, since I don't load the Stripe JS elsewhere), so you could track pageviews with that or something. That's unfortunate — I'll probably try to move the stripe stuff to a subdomain to avoid it — but I don't see it as a big problem.

The HTTP security model is pretty awful, so there may be something I'm missing, but I did think quite carefully about this, and allowing people to use arbitrary HTML and JS was an intentional choice.

Is there a particular threat model you see here?

[y4mi]

Just a heads up, a sister comment already pointed out the biggest "danger", but not what that means for your webapp:

Google will penalize your domain strongly as soon as anyone used your service for malicious content. You might even get blocked entirely if you are particularly unlucky.

That's also the reason why GitHub pages is hosted under github.io instead of GitHub.com for example.

[dharmab]

Safe Browsing is a must-consider for anyone hosting user-submitted content.

[psychometry]

>allowing people to use arbitrary HTML and JS was an intentional choice

Oh, you'll be reversing this choice VERY quickly if your product gets any traction, I assure you...

[monkeynotes]

I don't actually see a problem. It goes against my gut reaction but given the pages that are published are entirely isolated there is no more of a threat than someone publishing whatever they want on another web host. There is no user information to hijack, no cookies, no login buttons, no local storage, no auth etc.

Yes, the pages can publish illegal information, be set up as phishing hubs, but none of that is as a result of JS being executable. Web hosts all have exactly the same risks to deal with, their users can also host anything they wish.

The owner's challenge is with the content they are opening up to hosting, and it will become an overhead to police that. If they decide to add buttons like "report content" then those will be able to be hijacked by the publisher and become useless.

[dharmab]

Google will flag the entire domain in Safe Browsing. Unless you are a big company with a legal team, getting off the Safe Browsing flag list is a days or weeks long nightmare.

[psychometry]

How are they isolated if you can inject JS that downloads resources from anywhere else? I mean, just to start:

- You have no CSP header that I can see.

- You do expose the server version in the headers, though.

- The site is available at a non-SSL-secured domain.

- There's no X-Frame-Options, X-Permitted-Cross-Domain-Policies, etc.

[monkeynotes]

My point is, the service simply hosts HTML, ostensibly this is the same as any consumer web host. So whatever attack vector you can think of exists on Dreamhost or Godaddy pages, for instance.

[psychometry]

I understand, but you can't have it both ways: You can either build a minimal Twitter clone that limits user-submitted content and not worry too much about security/abuse, or you can build a web host. The latter entails a comparatively enormous amount of responsibility you don't seem keen to take on.

[dharmab]

I have worked for companies that offered commercial web host services and it is a massive security undertaking. I'm still not 100% convinced it's possible to offer a profitable, truly secure web host without compromising on feature set.

[edoceo]

You become a pastebin of malicious JS.

[junon]

https://nsfw-attack-demo.thoughts.page/

(not actually NSFW, just there to serve a point)