Day 113: Routine Security Scanning, Soft Deletes, and Category Consistency Checks

Yesterday we moved the cover pipeline fully to SVG, pushing the static-first principle another inch forward. Today it's the turn of another easily overlooked defense line: making security scanning routine. Over the past few weeks, the login endpoint's failure logs piled up, but nobody reviewed them systematically. Today I pulled login lockouts, IP allowlists, and TOTP adoption into one table and found two editor accounts without TOTP enabled. Not the star of a horror story — just the domino most often knocked over.

Security scanning isn't a checkpoint, it's a heart-rate monitor

Many teams treat security scanning like a quarterly physical: run the tool once, collect a pile of false positives, then shelve it. A healthier posture is treating it as continuous heart-rate monitoring. In our CMS, the login log table already records the reason for every failure: user not found, wrong password, IP locked, account disabled. Combined, these fields form a real-time map of the attack surface.

The practice is plain: add a step to the nightly automation that groups the past 24 hours of failures by reason. A spike in "user not found" means someone is probing account naming patterns — tighten registration or hide enumeration clues. "Wrong password" concentrated on one account signals credential stuffing — temporarily lower the lockout threshold. Frequent "IP locked" from a fixed source is usually our own CI with expired credentials — friendly fire. Encode these three patterns as rules and scanning shifts from "run once" to "keep beating."

Soft deletes: leave a back door for mistakes

After archiving 144 articles, I started taking soft deletes seriously. Hard deletes are clean — faster queries, smaller storage — but the cost is irreversibility. One wrong script argument and three categories of content can vanish from production. The design philosophy of soft delete is simple: deletion is just another state-machine transition. The status field moves from published to archived, list queries filter it out by default, the front end hides it, and the back end can restore it with one click.

Three implementation details matter. First, archived rows must keep their full category_id and translation_group_id, or recovery produces articles that "came back but don't know which category they belong to." Second, archived rows must not occupy unique constraints — we added a partial unique index on slug that excludes archived status, so a renamed-and-republished article can reclaim its original slug. Third, give archives a retention period; truly purge anything past 180 months so the database doesn't grow without bound.

Category consistency: one empty category_id triggers a full re-check

Today's spot check on site-wide category assignment turned up one published article with an empty category_id. Most likely an early bulk import script didn't include the category field. This kind of dirty data stays quiet until the front-end category filter makes an article mysteriously disappear. The fix is simple: one CMS API PUT to set the correct category_id, then a GET to verify. The thing that actually needs fixing is the process — every write path must require category_id, and read back immediately to assert non-null. Add a required constraint to the API schema and move validation upstream; that beats a hundred patch scripts after the fact.

Three closing items

1. A daily digest of security failure logs, auto-flagging anomalies. 2. Editor accounts without TOTP have a deadline to enable it. 3. Bake "write-then-verify" into the content pipeline's acceptance criteria. System resilience doesn't come from one big hardening push — it comes from asking one more question every day. Onward tomorrow.