reviewmy / Security
Two dangerous things, deliberately contained.
This product fetches URLs you choose and runs the code that comes back. Both are necessary, and both are only safe because of what is around them.
This page is a draft. It is accurate about the security model, but it has not been reviewed for what a public page should disclose. Treat it as a description of how the product works rather than a certification.
The model
What is actually dangerous here.
Most of a review tool is unremarkable. Two parts are not, and everything else in the design follows from containing them.
- It fetches arbitrary URLs from the server
- You give us an address and we fetch it. The content that comes back decides what gets fetched next. Left unconstrained that is a server-side request forgery engine, so the fetch path is deny-by-default: no non-http schemes, no URL credentials, no database or mail ports, no name that can only resolve internally, and no private or link-local address, including the cloud metadata range. Every redirect hop is re-checked rather than followed automatically, because a one-shot check at the entrance is bypassed by answering with a redirect to somewhere private.
- It runs someone else’s JavaScript on our origin
- Instrumenting a page means our code and the page have to share an origin. That is a cross-site scripting engine unless the origin is worth nothing, so reviewed pages are served from a separate origin that holds no session, no token and no data. A hostile page gets full run of an origin with nothing on it.
Containment
What stops it reaching further.
Each of these bounds a different adversary: the reviewed site, someone holding a share link, and the project owner themselves.
- Share links are scoped, not global
- A link carries a signed token naming one project. It reaches that project’s reviewer surface and nothing else. It cannot be used as a general web fetcher, and it cannot read another project.
- Secrets are encrypted, and separately keyed
- A connected GitHub token has to survive a round trip, so it is encrypted at rest rather than hashed. The encryption key is derived from the application secret under its own purpose label, so it is a different key from the one used for signing. API tokens, which only ever need comparing, are hashed instead.
- Trackers do not run during a review
- Analytics and advertising requests on a reviewed page are answered locally in the shape the page expected, rather than forwarded. Reviewing a page does not hand your reviewers to a third party’s tracker.
- The owner’s allow-list bounds the reviewer, not the internet
- Each project carries a host policy its owner sets. It is what stops a reviewer steering the proxy somewhere the owner did not intend. It is deliberately not the SSRF defence, which sits underneath it and applies to everyone including the owner.
Reporting
Telling us about a problem.
If you have found something, we would rather hear it early and awkwardly than late and publicly. Write to us through contact with enough detail to reproduce it. We will confirm we have it, tell you what we found, and credit you if you want the credit.
There is no paid bounty programme today. We will say so plainly rather than implying otherwise.