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?
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.
Oh, you'll be reversing this choice VERY quickly if your product gets any traction, I assure you...
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.
- 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.
(not actually NSFW, just there to serve a point)