Hacker News Reader

The most dangerous part of XSS is what developers don't know is possible. There are lots of sinks and sources and the more features browsers support, the more surface area is exposed.

Lots of developers intuitively notice reflective XSS, but fewer notice persistent XSS and even fewer know about DOM-based XSS. Each of these has several, even dozens, of sinks and sources to check + be aware of.

I think your offerings would be vastly more valuable if you had a CSP policy generator that defaults to the strictest possible settings, allowing the user to opt out / loosen some rules. Perusing your docs, you only describe a small subset of what CSP is capable of. Your average user is short on time and will likely copy-paste your example policies as their first implementation iteration.

It's important to explain that every page on their domain should be protected by a CSP policy. Protecting just a subset of the domain means that there is still vulnerable surface area.

Iframe embeds. Injected forms. Injected IMG tags. Injected meta tags. Data URIs. SVG DOM events. LocalStorage. Cookie overflow attacks. Charset sniff attacks. Charset attacks against specific databases. IE CSS expressions. Image/HTML + JS Polyglots. etc.

A developer that isn't familiar with all of the possible attacks is likely to not make the CSP as restrictive as needed. I highly recommend if you are going to tackle XSS, try and aim to provide value for all XSS attacks, not just the easiest to defend against.

Also, you should provide resources to explain why XSS is dangerous, what is potentially at risk, how much companies pay for XSS on bug bounties, and resources for the developer to know how to craft a successful CSP policy. Without these, you aren't selling your value proposition.

Thank you for your feedback! More resources and education material for developers will be coming very soon.

The default policy we provide is report-only. When we started we provided a very strict policy, but it broke too many apps. It was a major turn down for a lot of adopters. We are constantly evolving and are currently working on a feature that automatically generates tailored (stricter) policies depending on the reports we receive.

Thanks for doing this, I'm definitely going to consider it since we're implementing token based authentication and my friends have told me XSS is what I should be concerned about there.

How did you choose to go with a trial period instead of a freemium model like slack?

The issue my startup has with trial periods is that it's like "you have 14 days to start generating revenue". Freemium is better for us because it's like "You can learn about our service, and use our service while your staging your release, and when you launch if you're viable (traffic+revenue), we'll be your partner (ie. charge you)".

That's how slack kept us, and Salesforce lost us.

We shouldn't have to worry about paying while we're still learning how to use your service. If I haven't on-boarded it by the time the trial runs out, I'm going to cancel it.

Then again, I don't know your costs, so forgive me if I'm wrong.

You are absolutely right, trials are difficult when there is a integration step that might take a week. We consider the trial to start once you are fully integrated, not when you sign up.

A Freemium model is something we are interested in! We wanna support smaller projects with a free tier in the future.

Yeah, that sounds good to me. Being a bootstrapped startup, "pricing" is the first page I go to.

Yep. I do the same :)

interesting project, may I ask what is the vision to create a Billion Dollar company?

Please add pricing. And tip; to get startup founders, don't subscribe to the silly moniker that startup's price themselves too low. I look at the low, mid and high end price by volume to estimate any new costs now and 6 months down the line. Way too many overpriced services cause it's in vogue right now based on VC's saying it is. Certainly what you are doing is interesting. Nice work.

Small suggestion: your docs could use a little work. The language switching is broken, and the history state is broken, so when you click around the docs, you quickly end up with 20+ entries in your history.

Also, the site could definitely use more copy: how do CSPs work? How does the app work in general? Right now the only real details are in the documentation.

Also also, what information ends up back on your servers? Is any user data relayed through an API?

It's a very cool idea, just non-obvious at first glance what exactly it does :)

That is great feedback! Some of this was on our "immediately post-launch" todo list. Expect us to implement everything you just mentioned over the coming days.

> managing changes to the policy and having a reporting endpoint that gives you insights into what is being violated is still difficult.

Is this targeting management at companies with multiple products? As a developer I just use Django Middleware to add this line to all our responses and call it a day:

response['Content-Security-Policy'] = "default-src 'none'"

(Well, we still sanitize all our inputs and have the headers to block XSS reflection, but there's still not much complexity.)

Setting a CSP header can be simple but managing changes to it can get difficult. Especially as team members add or remove services from the app (Intercom, Google Analytics, etc.)

We also provide a reporting endpoint that captures all violations. Do you currently use a CSP header with a report-uri setting?

Have you actually found much value from these reports? Most people I talk to tell me they're full of garbage.

Noise is a problem and we are in this fight to improve exactly that.

There is clearly noise, but is there any signal at all? I wouldn't be surprised if there was no signal to be found.

There is a lot more signal than noise, especially they way we aggregate the security reports. CSP can be deployed in report only mode, which provides a great way to detect how your policy has to come together.

I guess in my mind signal == attacks, but I guess there's also value in having reports when your policy broke things if you don't have other methods for detecting that, or if your integration tests disable CSP.

Ahh that makes sense. We have an API-driven SPA, so our API is just banned from returning anything fun. But I can see how this becomes an for apps with server-side rendering based on how annoying it is to manage the CSP on our front end.

I think Google Webmaster tools report some XSS vulnerabilities. I'm not suggesting their detection is in any way as sophisticated as your solution - but do you see internet search giants offering and improving this sort of service as threat to you in the long term?

Congratulations on the launch though, don't think this product is targeted towards us though so probably wont get a chance to try it but love the objective.

Thank you!

Google Webmaster tools has made an effort to help fight XSS vulnerabilities by providing some educational tools to devs (among other things). It's not a solution in the same realm as ours, for example they don't collect any violations and show you detailed reports on where something bad happened.

I don't see Google as a threat to us at all. We actually sat down with them at their SF office last week to work closely together on how they can quickly provide a better Content Security Policy feature set to their cloud customers.

For PHP integration, have you considered hooking into CSP-Builder? (It's MIT licensed, so you can just make a private fork for internal use forever, but if you upstream your changes, I'd greatly appreciate it.)

https://github.com/paragonie/csp-builder

Yes we are looking at this. We will release a more integrated solution for PHP soon + docs.

Are you in the same space as Tcell.io? I think they have been doing this for a few years now.

I actually have never heard/seen Tcell.io so I can't speak to them and what they do. Will check it out though!

Watch out you got a typo on the front page: "A central dashboard shows all secuirty events and directs your attention to the exact part of your application that has issues" - security is spelled wrong

Thanks for finding this one. Just fixed it.

Offtopic - wow, so the links in submission text are clickable now, or is it a special kind of submission?

We did this for Launch HN and Show HN to lessen the penalty for making a text submission. There's a quality of density, and I would even say intimacy, in the text launches that fits well with HN.

I don't want to play with my API headers, if you can verify with TXT record on my domain, that would be great.

I thought that this was related with the verification but it looks like a feature of the browser.

No domain verification is required at this point. Content-Security-Policies are ideally delivered through the HTTP response headers and then enforced by the browser. We are working on making the integration as easy and smooth as possible.

What does your service cost?

looking for this for months. can't wait to test it.

This is awesome! Let me know if I can help you getting started.

Launch HN: Templarbit (YC S17) – Protect Your Web Apps from XSS Attacks