How RentnRide is secured

Staff sign in with a phone number and a PIN on a device the company owner paired. A PIN is a short secret, so the design assumes it is guessable and makes the guess useless.

PIN hashes are salted per staff member

The PIN itself is never stored. What is stored is a SHA-256 hash of the staff member own account identifier combined with the PIN, so the same four digits chosen by two people produce two unrelated hashes and one precomputed table cannot open every account on the platform. An unsalted PIN hash is treated as a build failure here, not a code-review note.

Access tokens last fifteen minutes

The token a signed-in staff member carries expires in fifteen minutes. A copied token is therefore useful for minutes, not for months, and revoking access does not depend on the thief cooperating.

Refresh tokens are device-bound and rotate on every use

Each paired device holds its own refresh token, and only a hash of it — salted with the device identifier — is stored, so a leaked table cannot be replayed as-is. Every successful refresh issues a new token and invalidates the old one in the same conditional write.

A reused refresh token revokes the device

If a superseded token is ever presented — by a thief, or by the real device after a thief has used it — the device is revoked rather than the request quietly failing. The staff member signs in again with their PIN; whoever copied the token has nothing. A silent failure would leave the attacker copy working, which is the entire reason this check exists.

Handover photographs, damage photographs and vehicle documents are stored as files in object storage. Four things are enforced on the way in.

The file name is built by the server, never by the client

Every stored object is named with the owning company identifier as its first path segment, and the rest is generated. The client supplies no part of the name and the file extension comes from the verified content type rather than from the uploaded filename — a filename is untrusted input, and a path that climbs out of a directory is also a filename.

The size cap is applied before the file is held

A declared length over the ceiling is refused without reading a byte, and one that lies costs at most the ceiling before the upload is abandoned. Reading the whole file and then measuring it means already having paid for it.

Counts and request rates are capped, and refusals are the safe direction

The number of objects per booking is capped, counted from the storage itself rather than from a number that could drift, and upload requests are capped per address and per company. An upload path is a spending path, so every cap here fails closed and each one emits a record when it trips.

How this differs from the intended design, plainly

The intended design has the browser upload straight to storage using a pre-signed link, so the bytes never pass through our servers. That needs a storage access key pair which is not provisioned, so today the bytes DO pass through the server that applies the checks above. Every guarantee in this section holds either way; the change when it lands is about cost and throughput, not about what is enforced.

Actions that change records are written to an audit log: which staff account, which record, which action, when, and the request identifier that ties it to the server logs for that moment.

The actor is taken from the verified session token and never from the request body, so it cannot be forged by whoever is making the request. The rows are not deleted, by anyone, including us — a log the subject of an entry can remove is not a log. What is stored alongside an entry passes an allowlist filter first, so an audit row never becomes a copy of a request body with customer details in it.

Errors are typed with stable codes rather than thrown as raw messages, and a stack trace never reaches a user. What a person sees is a message in their own language and a request identifier they can quote; what we see is the same identifier attached to the stored fault.

Fault records are deduplicated so a crash loop increments a counter instead of writing a row per occurrence, and every payload passes an allowlist filter before storage that removes phone numbers, names, identity-document values, tokens, PINs and file addresses. That filter is tested against realistically shaped data, because a redactor nobody has watched fail is not a redactor.

The site you are reading has no database, no storage, no key-value store and no secret of any kind attached to it. It cannot reach tenant data, so a flaw in it cannot expose any — the strongest form of the isolation rule is having nothing to isolate.

It also collects nothing. There is no form on any page, no address that accepts a submission, and its content security policy forbids the browser from submitting a form at all — three independent layers, so that one mistake does not quietly create an intake path. Everything it loads comes from this site alone.

If you have found a problem, tell us before you tell anyone else, and we will not take any legal action against you for having looked, provided you did not access, alter or keep anybody data beyond what was needed to demonstrate it.

Send it to the security address below where one is published. This site also serves a machine-readable contact file at the standard well-known address when a contact has been configured. We acknowledge within three working days, tell you what we found, and are glad to name you when it is fixed if you would like that. There is no paid reward programme, and saying so is fairer than letting you find out after the work.

No external security audit or penetration test has been carried out on this platform, and it holds no security certification. Saying otherwise is common on pages like this one and is checkable, which is why it is not said here.

Everything above describes the platform. It cannot describe the phone a staff member left unlocked on a counter, a PIN written on the wall, or an account shared between four people — and those are where real losses at a rental counter actually start. The terms of service ask each company to give every staff member their own account for exactly that reason.