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

Paypedia is a reference site served as static pages. It has no accounts, no passwords, no cart, and no application server. This page explains how to report a vulnerability and what is actually in place, without promising anything more.

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.

support@paypedia.org
Languages: French, English.
Acknowledgment within 5 business days.

The site runs no bug bounty program and promises no reward. It does commit not to take action against research carried out in good faith: without degrading the service, without accessing anyone else’s data, and without disclosure before a fix. A fix is published as soon as it is ready, and the reporter is notified.

What the site does not hold

The best way to protect data is not to hold it. The site creates no accounts, asks for no passwords, sends no email, and stores no payment details. The checkout demo pages contain no card entry fields: they are mockups, not forms.

How the site is built

Pages are generated in advance and served as-is 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.

Nothing can be written from the browser: the project’s database rejects every read and every write coming from the web. The BIN lookup used to record prefixes missing from the reference data there; that collection has been removed, because an eight-digit prefix can’t be told apart from the start of a real card number.

The IBAN and BIN tools

IBAN validation and card prefix analysis run in your browser. The full number is sent nowhere. To answer, the browser downloads a slice of reference data: by the two-letter country code for an IBAN, by the first three digits for a card. The host therefore sees those characters, in the requested URL, and nothing more.

This is not a guarantee enforced by a browser mechanism. It is what the code does, and you can verify it by opening the Network tab of your browser’s developer tools during a lookup. You’ll also see requests from Google’s ad script, which loads on every page; Paypedia passes it nothing you type.

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 locked in by an automated test, so they cannot disappear unnoticed.

Strict-Transport-Security: the site can be reached only over HTTPS, enforced for one year.
Content-Security-Policy: restricts where scripts, images, and connections can come from.
X-Frame-Options: DENY: the site cannot be framed inside another page.
X-Content-Type-Options: nosniff: browsers may not reinterpret a file’s type.
Referrer-Policy: other sites receive only the domain in the Referer header, not the page’s full URL.
Permissions-Policy: geolocation, microphone, camera, and the payment API are disabled.

Two caveats, stated here rather than left for you to discover: the content security policy allows inline styles, which weakens its protection against style injection, and it names the analytics and advertising domains the site uses. Those allowances are the price of funding the site, and they are visible in the HTTP response of any page.

Scope

This policy covers the paypedia.org site and the files it serves. It does not cover third-party services called from its pages, which are their publishers’ responsibility, or the sites that articles link to. The privacy policy details what data is processed and who receives it.