JEKrayPro security overview

Version 1.3, 5 October 2026

How JEKray and JEKrayPro are built and protected, for information security teams reviewing them. It answers most of a typical supplier security questionnaire; we are glad to complete yours as well. Questions: [email protected].

1. How it is built

The simulator runs in the browser. JEKray is a single web page served from jeksys.net. Every calculation runs on the user’s own computer. A bench leaves the computer only when the user saves it to the cloud, shares it, or exports it.
The cloud service (api.jeksys.net) is a Cloudflare Worker with a Cloudflare D1 database for accounts and current benches, Cloudflare R2 storage for version history and thumbnails, and Cloudflare Workers KV for short-lived sign-in state. It has no servers of our own to maintain or patch.
The website is static and hosted by GitHub Pages. It holds no account data.
Payments go through Stripe’s hosted Checkout, customer portal and invoices. Card numbers never reach our systems.
The cloud service is separate from our other systems: it shares no database, storage or secrets with them.

2. Sign-in and sessions

Users sign in with Google or Microsoft (OpenID Connect, with PKCE). We never see or store passwords. We ask Google and Microsoft only for the basic sign-in scopes, and read nothing from a university’s directory.
Microsoft sign-in accepts university and work accounts only. A person is identified by their tenant and object identifiers; their email address is taken from their sign-in name, whose domain the tenant has had to prove it owns, never from the editable email claim, and guest accounts give none.
Each sign-in is tied to the browser that started it by a one-time state value, which expires after 10 minutes.
Accounts are never merged because two sign-ins share an email address. A second sign-in method can only be linked by someone already signed in.
A session is a 256-bit random token in a cookie that is Secure, HttpOnly, SameSite=Lax and limited to api.jeksys.net. We store only its SHA-256 hash, so a copy of our database would not let anyone sign in. Sessions last 30 days from last use and end on sign-out or account deletion.

3. Access control

Every request is checked against the user’s membership and role in the workspace concerned (owner, admin, editor or viewer). Another workspace’s benches are indistinguishable from ones that do not exist.
Changes need an allowed origin (jeksys.net), as well as the session cookie, so other websites cannot act for a signed-in user. Only jeksys.net may read the service’s responses in a browser.
Saving needs an active plan; reading and exporting never do, so people can always get their data out.
Requests are rate limited: sign-in per network address, changes and slower actions (eligibility checks, exports, payments, account deletion) per person, and every request body is capped in size however it is sent.
A university’s licence administrators see only counts, and can invite or take off people by email address; taking someone off answers the same whether or not they have an account.
Our own administration of university licences uses a separate 256-bit key over HTTPS, and is switched off entirely when the key is not set.

4. Data protection in transit and at rest

All traffic to the website and the service is over HTTPS.
Cloudflare encrypts the database, storage and key-value data at rest.
API keys and other secrets are held as encrypted Cloudflare secrets, never in our source code. Our Stripe key is a restricted key with only the permissions the service needs.
The app runs under a content security policy that lets it load code and images, and send data, only to jeksys.net and the service; benches, including ones opened from share links, are only ever shown as text, never run, and the formulas in masks are parsed by the app itself, with only arithmetic and named maths functions allowed.
The service’s answers carry headers that stop browsers treating them as pages, framing them, or using them over plain HTTP.
Uploaded data is checked: a bench must be a valid bench file of at most 2 MB; a thumbnail must really be a WebP, PNG or JPEG image of at most 128 KB, and is served back so that browsers cannot treat it as anything else.
Stripe webhooks are accepted only with a valid signature made within the last five minutes. Each event is processed once, and the subscription’s state is always fetched from Stripe rather than trusted from the message.

5. Backups, history and deletion

Every bench keeps a version history: the last 50 saved versions, and one a day for 90 days. Users can restore any of them.
Deleted benches stay in a bin for 30 days, then are deleted with their history.
The database can be restored to an earlier point in time using Cloudflare D1’s recovery feature.
Users can export all their benches at any time and delete their account. Account deletion removes their workspace, benches, history, sign-ins and sessions at once.

6. How changes are made

All code is kept in version control, with the history of every change.
The service has an automated test suite (over 100 tests, including tests that one account cannot reach another’s data, that writes from other websites are refused, and that billing and deletion behave correctly), and the simulator has over 400 automated checks. Both are run before changes are released.
Database changes are made through numbered migrations.
Before the first users, the whole service and app were reviewed for security, with a test that calls every route naming another person’s data as someone else, signed out, and from another website, and checks that nothing is returned or changed. The service runs no third-party code.

7. People and administration

JEK Systems is a small business. Administrative access to the hosting, payment and code accounts is held by its director only, and each of those accounts is protected by two-factor authentication.
We do not look at users’ benches, except when a user asks us to help with one.

8. Incidents

If we find a security incident affecting personal data, we contain it, assess it, and notify the Information Commissioner’s Office within 72 hours where the law requires, and affected users.
Universities with a licence are told without undue delay, and we aim to do so within 48 hours of becoming aware (see Data protection for universities).
Please report security problems to [email protected]. We will acknowledge reports within two working days and will not take action against good-faith research that avoids harm to users and their data.

9. What we do not have yet

An independent penetration test or a formal certification such as Cyber Essentials or ISO 27001. We will share results when we have them.
Sign-in through the UK Access Federation (SAML). University single sign-on is through Microsoft accounts.