Security. How to report a flaw, and what the site does with your data.

Paypedia is a documentation site served as static pages. It has no accounts, no passwords, no basket and no application server. This page sets out how to report a vulnerability, and what is actually in place, without promising anything beyond that.

Reporting a vulnerability

Write to the address below. Describe what you found, how to reproduce it, and what an attacker could gain from it. A minimal proof of concept helps more than the output of an automated scanner.

The site runs no bounty programme and promises no reward. It does undertake not to pursue research carried out in good faith: no degradation of the service, no access to a third party’s data, no disclosure before a fix. A fix is published as soon as it is ready, and the reporter is told.

What the site does not hold

The best protection for a piece of data is not holding it. The site creates no accounts, asks for no passwords, sends no email and stores no payment credentials. The checkout demonstration pages contain no card entry field at all: they are mock-ups, not forms.

How the site is built

Pages are written in advance and served as they are by the host. There is no web-facing database, no admin interface and no server-side code execution: the usual attack surface of a dynamic site does not exist here.

Only one write is possible from the browser: recording a card prefix the reference data does not know, on creation only, in a collection where the document id is the prefix itself. No read is allowed from the web, and the rule that governs it is public.

The IBAN and BIN tools

Validating an IBAN and analysing a card prefix are computed in your browser. The complete number is sent nowhere. To answer, the browser downloads a fragment of reference data: the two letters of the country code for an IBAN, the first three digits for a card. The host therefore sees those characters, in the address requested, and nothing more.

This is not a guarantee enforced by a browser mechanism: it is what the code does, and you can check it by opening the network tab of your developer tools during a lookup.

What the server sends to the browser

The headers below are the ones the host adds to every response. They are declared in the site’s configuration file and pinned by an automated test, which stops them disappearing unnoticed.

  • Strict-Transport-Security — the site is reachable over HTTPS only, for one year.
  • Content-Security-Policy — limits the origins of scripts, images and connections.
  • X-Frame-Options: DENY — the site cannot be framed inside another page.
  • X-Content-Type-Options: nosniff — no re-interpretation of a file’s type.
  • Referrer-Policy — the full address of a page is not passed to third parties.
  • Permissions-Policy — geolocation, microphone, camera and the payment API are disabled.

Two caveats, stated here rather than discovered: the content security policy allows inline stylesheets, which weakens its protection against style injection, and it names the analytics and advertising domains the site calls. Those allowances are the price of funding the site; they are visible in the HTTP response of any page.

Scope

This document covers the paypedia.org site and the files it serves. It does not cover the third-party services called from its pages, which are the responsibility of their own publishers, nor the sites the articles link to. The detail of the data processed and its recipients is in the privacy policy.

Privacy policy · Legal notice