This site is subject to severe XSS via the post mechanism. Just entering <script>alert(1)</script> works. So be careful when going to links. See https://hacker.thoughts.page for a demo
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.
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.
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.
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.
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.
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.
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.
I didn't either until I started my current job back in April and found them in a frenzy trying to firstly figure out what XSS is and secondly trying to patch all their systems before the end of the month. Fun times.
