A bilingual site, and a security pass on a live system

The problem

A non-profit association connecting Chinese and Bangladeshi universities needed its entire website published in English and Chinese, edited by staff with no developer involved. Programmes, services, events, news, leadership, membership tiers.

It was already live when I audited it. Three write endpoints had no authentication at all. One of them let anyone overwrite the association’s public contact email and address. That is a ready-made phishing primitive: change the address, wait for the enquiries.

What I did

I wrote a severity-graded register of 68 findings with per-file line references, then closed them.

The authentication callback was granting admin to every row in the users collection, which made the entire role check decorative. The middleware was returning next() for every admin path. The image configuration allowed any hostname, which is an open image proxy anyone can launder traffic through. A member could approve their own membership application. Unpublished drafts leaked. A failed file read returned the server’s filesystem layout.

All of that is now closed, and the register is a document a client can read.

Rate limiting became two layers. There is a signed state cookie with four rule tiers. Behind it there is a separate in-process counter, checked first, because a cookie-only limiter is reset by discarding the cookie, which is exactly why the original login brute-force cap never fired. The process manager is pinned to a single instance because that counter lives in process memory. That is a real constraint and I would rather state it than hide it.

The upload path rejects on content length before it buffers anything, then re-checks the bytes actually read, because a client-supplied length cannot be trusted. The underlying library’s own size limit had been sitting at its 200 MB default while the handler believed it was enforcing 10 MB. Everything accepted is transcoded to WebP under a random filename, which is what actually closes the stored-XSS vector rather than filtering extensions.

Bilingual content is stored as pairs. Every item exists as an English row and a Chinese row sharing a slug, written together in one operation. The update path refuses to run if the pair count is not exactly two. Bilingual sites almost always rot into English-only rows with orphaned translations. This makes that structurally hard.

Why this is the one I show first to a nervous client

Anyone can show you a feature they built. Very few people can show you a written before-and-after security register on a production system, with the commits that closed it.