Boring but Critical: The Security Work We Never Announced

The work that gets no announcement

Every product has two kinds of engineering: the work you announce and the work you do not. The announcement-worthy work is features — new capabilities, visible improvements, things you can put in a changelog and point users toward. The other work is everything that keeps the product safe, stable, and trustworthy. It almost never makes the release notes.

This is backwards. The invisible work is often more important than the announced work. A feature that ships on a platform with a cross-site scripting vulnerability is a feature that ships with a liability. An onboarding flow that converts well but has no spam protection is an onboarding flow that will be gamed the moment anyone notices it. The boring work is the precondition for everything else mattering.

Over the past six weeks, we shipped a lot of boring work. This post is the announcement it never got.

The XSS fix

Cross-site scripting vulnerabilities happen when user-controlled content is rendered in the browser without proper sanitization. The attack is simple: an attacker injects a script tag or an attribute that executes JavaScript in the context of your page, which means in the context of your authenticated session.

We found the issue in an input field that was rendering task descriptions with partial HTML support — a feature that let users bold text and add links. The renderer was not sanitizing attributes correctly, which meant a crafted input could inject an event handler. Nobody exploited it. We caught it in an internal security review before anyone outside the company had the surface area to find it.

The fix was not complicated, but it required discipline across every place user-generated content rendered in the application. That is not one file. It is a sweep: find every render point, verify the sanitization policy, add missing sanitization, add tests that verify the policy holds for the inputs that bypass naive filters. That sweep took a day. It produced no visible change to any user. It was the right use of a day.

Admin gating

The admin interface had insufficient authentication on several endpoints. Specifically: certain administrative actions could be performed by any authenticated user, not just users with administrative privileges. The gate was checked on the frontend but not consistently enforced at the API layer.

This is a classic mistake. Frontend gating hides UI elements from non-admin users, but it does not prevent API calls from being made directly. Any user who knew the endpoint and had a valid session token could have invoked administrative actions.

The fix was adding server-side privilege checks to every admin endpoint — not trusting the frontend to have done the right thing, but verifying the session's role at the API layer before executing anything with elevated privileges. We also added audit logging to admin actions, so there is now a record of every administrative change including who made it and when.

The broader principle: frontend-only authorization is not authorization. It is theater. Real authorization happens at the API, where the server controls the outcome.

Anti-spam

When the onboarding demo went live, we started seeing automated signups within 48 hours. Bots testing the signup flow, probing the API, attempting to create workspaces at scale. This is normal — any publicly accessible signup endpoint will be discovered and tested.

We added rate limiting at the endpoint level: a progressive backoff that triggers after a threshold of requests from a single IP or user agent within a time window. We added honeypot fields to the signup form: invisible inputs that human users never fill in but that bots fill automatically, identifying themselves. We added behavioral signals: minimum time between form field completions, absence of mouse movement, request headers that do not match a real browser.

None of these measures is individually sufficient. Together, they make automated abuse expensive enough that the traffic dropped and has stayed down. The legitimate users — humans, moving at human speed, using real browsers — experience no friction. The bots hit the rate limit and stop.

We also added internal account exclusion to our signup metrics at the same time, which is a related problem described in a separate post. The short version is that our own signups were polluting our conversion data, making the funnel look healthier than it was. Cleaning the metrics is not a security issue, but it is the same kind of invisible work that makes the visible work meaningful.

Dependency audit and updates

We ran a full dependency audit — every package in the frontend and backend dependency tree, checked against known vulnerability databases, flagged against their published security advisories.

The audit found twelve packages with published vulnerabilities. Two were in the critical or high range. We updated all twelve. Several updates required API changes on our side because the new versions introduced breaking changes. That work — the adaptation to the updated APIs — is invisible to users but is what keeps the product running on packages that are actively maintained and not known-vulnerable.

Dependency management is a recurring obligation, not a one-time task. We now have an agent running the audit on a schedule and filing tasks for any new findings. The fix for stale dependencies is the same as the fix for any other form of drift: a system that catches it automatically rather than relying on someone to remember to check.

Why it matters that we write about this

Security and reliability work does not get celebrated because there is nothing visible to celebrate. No user sees the XSS patch. No user feels the difference between an unsecured admin endpoint and a secured one — unless the unsecured one gets exploited, at which point every user feels it.

The incentive structure pushes toward announcing features and skipping the boring work. Building a product on that incentive structure produces a product that looks good until it does not. The companies that stay trustworthy are the ones that do the boring work on a schedule, whether or not it is worth announcing.

This post is our attempt to shift that incentive slightly. The boring work happened. It mattered. It deserved to be documented, even if it will never trend.

Do your boring work. Write it down somewhere. That is the culture that produces software you can trust.