Sanigen Laravel Package

Product Decisions This Supports

• User-generated content (UGC) hygiene as a default, not a per-feature afterthought. v1.9.0 makes sanitization automatic and recursive on Eloquent attributes, which means "we sanitize on write" becomes a model-level policy instead of a thing each feature team remembers to do. That directly supports roadmap bets on comments, reviews, profiles, support tickets, marketplace listings, or any surface where end users write text.
• Multi-language / translatable content. Real Spatie Translatable support (HasSanitizedTranslations) removes a recurring blocker for localisation roadmaps: today, sanitizing translated fields usually means bespoke loops per locale, which is where inconsistency and escaping bugs live. If internationalisation is on the roadmap, this closes a known gap.
• Structured / JSON payloads (heterogeneous form data, CMS blocks, saved filters, webhook ingestion). Dot-notation and wildcard paths mean PMs can accept "free-form-ish" JSON structures from the product side without engineering rebuilding a sanitizer per shape. This unlocks feature scope that would otherwise be descoped to "fixed schema only."
• Build vs buy: leans buy/adopt. Sanitization is a deceptively expensive thing to build — Unicode normalization (NFC), newline variants (Windows/old Mac), negative decimals, HTML allowlists, depth and item-count limits. v1.9.0 shipped fixes in exactly those long-tail areas, which is the signature of a library that has absorbed real bug reports. Adopting is cheaper than owning that tail.
• Predictability as a product requirement. "Single-pass," "deterministic precedence," "one matching pipeline per string leaf" matters commercially when output is stored, diffed, hashed, or shown in audit logs. Deterministic sanitization means re-saving a record doesn't silently mutate content — which protects version history, exports, and content moderation workflows.
• Fail-closed security posture as a compliance argument. Shared depth/item-count/length limits across a whole traversal, plus failing closed on objects, resources, malformed paths, and specificity conflicts, is the kind of behaviour that satisfies a security review or questionnaire without a bespoke threat model. Useful evidence for enterprise/regulated deals.
• No-leak exceptions. "Structured processing is atomic and does not expose submitted values in exceptions" supports logging/observability decisions — you can ship error reporting without a PII review per release.
• Low-cost deprecation. The recursive: prefix deprecation is a cleanup, not a break — it stays compatible. This is a "schedule the tidy-up, don't schedule a migration project" decision.

When to Consider This Package

Adopt when most of these are true:

• The product is Laravel with Eloquent as the write path for user-supplied text, and you want sanitization bound to models rather than to controllers or form requests.
• You accept structured/untrusted JSON from clients, or you store Spatie Translatable fields that carry user content.
• You need consistency across many models and teams — the value is highest when "everyone sanitizes a bit differently" is the current state.
• Your threat model is stored-XSS and content-hygiene, with untrusted input arriving at moderate depth and volume (form payloads, CMS blocks, comments) — the new depth/count/length limits assume roughly this.
• Determinism matters: content is hashed, diffed, exported, versioned, or shown to moderators.
• You want security review artefacts (fail-closed behaviour, bounded traversal, no value leakage in exceptions) without writing them.

Look elsewhere or pair with something else when:

• You need a full HTML policy engine — strict allowlists with URI scheme filtering, CSS/property-level filtering, DOM-aware repair of malformed markup. A sanitizer that operates on string leaves is a complement to a DOM-based HTML purifier, not a replacement, for rich-text editors.
• You need schema/shape validation (required fields, types, business rules). That's Laravel validation / JSON Schema; this package cleans values, it doesn't reject them.
• Your writes are non-Eloquent, event-sourced outside models, or the stack isn't Laravel/PHP.
• You handle very large or streaming payloads where a bounded single-pass traversal with item-count limits will legitimately refuse work — verify the limits fit your largest real payload before committing.
• You need binary/file/media sanitization (image re-encoding, PDF scrubbing). Out of scope.
• The team cannot absorb a v2 cleanup of the deprecated recursive: convention — minor, but it should be on someone's list.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're standardising how we clean user-supplied content on a mature, narrowly-scoped Laravel library rather than maintaining our own string-handling code. The new release makes cleaning automatic and predictable across plain fields, JSON structures, and translated content, and adds hard limits so hostile or oversized input can't be used to exhaust the application. The business case is risk reduction (fewer stored-XSS and content-integrity defects), consistency (one policy instead of per-team conventions), and lower cost of compliance conversations (bounded processing, fail-closed behaviour, no user content leaking into error logs). No breaking changes; the one deprecation is backwards-compatible and can be cleaned up opportunistically.

For engineering (bullets to lead with):

• One pipeline, one traversal. Root rules now recurse automatically; each string leaf gets exactly one matching pipeline with deterministic precedence. sanitizeAttributes() processes each root once. You can delete hand-rolled recursive walkers and the recursive: prefix (still accepted, deprecated).
• Type fidelity preserved. Keys, structure, integers, floats, booleans, and nulls survive sanitization — so you're not accidentally stringifying typed JSON columns.
• Targeted addressing. Dot-notation and wildcard paths let you sanitize specific branches of heterogeneous JSON instead of nuking the whole document.
• Encoding correctness. Unicode NFC normalization and newline normalization (including Windows and old-Mac endings in plain_text) — output is stable for storage, comparison, and hashing. Negative decimals keep their sign; aliases like safe_html can now delegate to their base sanitizer.
• Security defaults are on. Depth, item-count, and scalar-length limits apply per full root traversal; objects, resources, malformed paths, and equal-specificity conflicts fail closed; processing is atomic and exceptions don't echo submitted values.
• Quality signals, with a caveat. Shipped with 138 tests / 405 assertions plus Pint, PHPStan, Composer validation, and audit. That's a healthy baseline for a focused string library, but the suite is small in absolute terms — before broad rollout, add our own characterization tests for the exact rule sets and translatable models we depend on, and confirm the depth/item-count limits against our largest real payloads.

For the roadmap conversation: this converts "sanitization" from a per-feature task into a platform capability, which is what lets us say yes to user-generated and localised content features without a security spike each time. Recommend adopting behind model-level traits, running it in shadow mode on one or two high-traffic models for a release, then expanding.