Security

Every assessment, page, finding, document and conversion belongs to one organization. A request for one belonging to another organization is answered as though the resource does not exist, rather than as a refusal — so the response does not confirm that somebody else’s scan is there.

That decision is made in a single function that every endpoint reading an assessment goes through. It is one place rather than a rule applied in dozens, which is what makes it something we can state rather than hope.

Signing in

A six-digit code emailed to the address on the account. The code is bound to the browser that asked for it, so a code read out over the telephone to somebody else is useless to them, and it expires.

Passwords

Not used, not shown, and not emailed. Where one exists in the database at all it is a scrypt digest with a per-user salt.

Sessions

A token sent in an authorization header, never a cookie — a cookie is attached by the browser to any request that reaches our API, which is the whole of cross-site request forgery. The token is stored as a SHA-256 digest, so a copy of our database is not a set of working credentials.

Secrets you give us

Encrypted at rest with a key held outside the database. Without that key the product refuses to accept a secret at all rather than storing it in the clear.

The assessment is passive. It follows public links with ordinary page requests, and that is the whole of it:

• It does not sign in to anything, and it does not submit a form.
• It does not attempt to get past bot protection, a CAPTCHA, or any access control.
• It obeys your robots directives. A site that refuses this crawler is refused.
• It will not reach a private network. Every address it is given and every redirect it follows is checked before the request is made, including addresses that resolve to internal ranges.
• It waits between requests and runs a bounded number at once, so a scan does not behave like a load test against your web server.

A PDF you upload to be fixed is kept beside its fixed copy for a week after fixing finishes, so you can compare and download them. Then both are no longer available, and are removed from our database within about an hour. Only your organization’s accounts can see either.

Converting a PDF to HTML works on a copy of it. That copy is deleted in the same database transaction that writes its converted result, and no part of the product serves those bytes back to anybody. The PDF you uploaded stays in its upload set for three days after you add it, like every upload. A converted copy stays available for three days after its conversion finishes, then is no longer available and is removed the same way.

Where a conversion involves our model provider, what is sent is that document’s own text and, where picture descriptions are on for that work, its pictures. Where a fixed PDF has tags and your account has picture descriptions on, each picture in it is sent to be described. With AI turned off, nothing is sent — see how we handle your documents for exactly what goes where.

The one address on this service a stranger may send data to is the endpoint our payment provider posts to. It authenticates the message rather than the caller: the raw body is verified against a shared secret in constant time, with a timestamp window so a captured delivery cannot be replayed, and a deployment with no secret configured refuses every delivery rather than trusting it.

What such a message may change is the payment status of an invoice we ourselves issued. It cannot name a customer, and it cannot create one.

If you have found a security problem, tell us here rather than through the support queue, which is measured in business days and read by people who cannot act on it. Write to security@missionlayersystems.com.

We do not publish a PGP key. If your report contains something you would rather not send in plain mail, send a first message saying so without the detail and we will arrange an encrypted channel before you send it.

Acknowledgement

Within 2 business days of your report reaching us.

Triage and severity

Within 5 business days of that acknowledgement, we will tell you whether we could reproduce it, whether it is in scope, and what severity we have given it.

While it is open

An update at least every 30 days, without you having to ask.

At the end

We tell you when it is fixed — or that we are not going to fix it, and why.

These are first-response targets, not repair times. We deliberately publish no deadline for a fix: how quickly one ships depends on severity, and a repair clock we could not keep consistently would be worth less to you than none. Severity decides priority, and the section below says how.

Critical

Immediate prioritisation. Work starts before other work.

High

Priority remediation, and it blocks the next release.

Medium

Assessed on risk, and remediated according to that assessment.

Low

Tracked and fixed on its merits, with the reasoning recorded.

We will tell you the severity we assigned and why. If you disagree with it, say so — we would rather argue about a severity than miss something.

• This application, its web interface and its API.
• The websites and subdomains we operate.
• Software we produce and deliver to a customer.
• Packages and container images we publish, where we have published any.

And what is not:

• Our suppliers’ own systems. Our source control, model, hosting and database providers each run their own disclosure programs, and we cannot fix their software. Tell us anyway and we will help you route it to the right one.
• Third-party open-source components, unless the issue is in how we use or configure one.
• Anything needing physical access to our equipment, or social engineering of us.
• Denial-of-service, volumetric or load testing.
• Scanner output with no demonstrated impact.
• Missing hardening headers or cookie flags with no exploit path — send them anyway; we will read them and record them as informational.

• Access, alter, take or delete anybody’s data. One record proving access is enough — stop there.
• Degrade the service for anyone else.
• Use a finding to reach further into our systems, or into our suppliers’.
• Publish before the window below has run.

We treat security research and disclosure carried out under this policy as authorised. If you act in good faith and stay inside the scope above, we will not bring or support legal action against you over that research, and we will not report you to law enforcement over it. If you step outside it by accident, stop and tell us — we will treat it as an accident.

That does not cover taking or destroying data beyond what is needed to show us the problem, degrading the service, demanding payment as a condition of telling us, or compromising somebody else.

We do not pay bounties. We would rather say so here than let you find out after you have spent your evening on it. We will credit you by name when we publish the fix, if you would like us to.

We ask for 90 days from our acknowledgement before you publish. In exchange we will keep you updated, will not use that time to sit on a fix, and will agree a shorter window with you if something is being actively exploited.

If we have not fixed it within 90 days and cannot agree an extension with you, publish. We would rather publish together.

A report is welcome in any form. This is what makes it quicker for us to reproduce and fix:

• What the issue is, in a sentence or two.
• Where — a URL, endpoint, parameter, package or file.
• Steps precise enough for us to follow.
• What an attacker gains, and what an affected party loses.
• Evidence — a request and response, a log excerpt, a screenshot. Please redact any third party’s data.
• How you would like to be credited, or that you would rather not be.
• Whether you intend to publish, and when.