Object Encryptor Laravel Package

Product Decisions This Supports

• Security posture / vulnerability remediation: This release closes a PHP object-injection class of risk (POP-chain / gadget abuse) in the decode path. It is a drop-in dependency bump that lets us claim a hardened deserialization boundary without a re-architecture project — a cheap, high-signal win for any security questionnaire (SOC 2 CC7, ISO 27001 A.8, customer due-diligence packets).
• "Encryption at rest" roadmap items: If we store serialized PHP payloads on disk, in queues, in cache, or in a DB column (job payloads, webhook bodies, integration credentials, deferred/long-running task state), this package is the encrypt/decrypt primitive. This patch is a prerequisite gate before we widen that pattern to more data stores.
• Build vs. buy: Reinforces "buy/adopt" over hand-rolling openssl_encrypt + serialize() wrappers. A hand-rolled equivalent would almost certainly ship the same unserialize() flaw, and we would not have a CVE-style patch stream to consume.
• Upgrade cadence policy: Sets the precedent that security-only patch releases (2.14.x) are auto-mergeable within the current minor — a useful test case for defining our dependency-update SLA (e.g., security patches within 7 days, no feature review required).
• Data-contract decision: Because the serialized format is unchanged, this does not force a data migration or re-encryption project. That removes the main cost driver from the decision — the remaining cost is purely a compatibility check, not a data-migration workstream.
• Vendor/stack concentration risk: Package is Keboola-maintained and PHP-ecosystem-specific. Adopting it further deepens a dependency on a niche maintainer; a decision to expand usage should be paired with an exit/fallback note (native Laravel Crypt or sodium_crypto_secretbox).

When to Consider This Package

Adopt when:

• We are a PHP/Laravel service that must persist serialized PHP values (arrays, DTOs, nested structures) at rest and needs symmetric encrypt/decrypt with a shared key.
• We are running outside or alongside Laravel's Crypt facade — e.g., shared libraries, workers, or Keboola-ecosystem jobs where a framework-agnostic encryptor is needed.
• We need backward-compatible decryption of a body of already-encrypted production data and cannot afford a re-encryption window (as with this release).
• The threat model includes an attacker who can write to our ciphertext store (DB read/write, cache poisoning, queue injection) — that is exactly the scenario this hardening addresses.
• We want a small, single-purpose dependency rather than a full KMS/envelope-encryption platform.

Look elsewhere when:

• We are a standard Laravel app encrypting values with the framework — Crypt::encryptString() / encrypt() already covers this with authenticated encryption and key rotation via APP_KEY; adding a second crypto library increases surface area for no gain.
• We need envelope encryption, KMS/HSM-backed keys, per-tenant key isolation, or automated key rotation — this package is a primitive, not a key-management solution.
• Encrypted payloads must be read by non-PHP services (Go, Node, Python). The wire format is PHP serialization; cross-language consumers will need a parallel implementation or a format change.
• We need field-level, searchable, or deterministic encryption for querying encrypted columns.
• The data is not PHP-serialized (raw JSON, protobuf, avro) — pick a format-appropriate crypto layer instead.

Mandatory pre-upgrade validation for 2.14.2: allowed_classes => false means any decrypted payload containing objects will now yield __PHP_Incomplete_Class instead of a hydrated object. Run a payload-shape audit: sample real ciphertexts and confirm they decode to scalars/arrays only. If we legitimately encrypt objects, this patch is behaviour-breaking for us despite the "backward compatible" note, and we need an allow-list wrapper or a migration to array payloads before bumping. That audit is the only real work item here.

How to Pitch It (Stakeholders)

To executives / risk owners (30 seconds): A security patch shipped for a crypto library we use to protect stored data; the flaw would have let a maliciously crafted encrypted payload instantiate arbitrary classes in our process — a stepping stone to remote code execution in the worst case. The fix is a one-line version bump, requires no re-encryption, no downtime, and no change to stored data. It closes a finding that would otherwise appear in customer security reviews. Cost: a few engineering hours, mostly verification. Recommendation: approve and ship this sprint.

To engineering leadership: Upgrade keboola/object-encryptor to ^2.14.2. Zero API changes, zero format changes, existing secrets decrypt unchanged — but unserialize() now runs with allowed_classes => false, so any code path that legitimately round-trips PHP objects through the encryptor will start receiving __PHP_Incomplete_Class. The single action item is a payload-shape audit of production ciphertexts; if all payloads are arrays/scalars, this is a clean merge. Add a regression test that asserts non-scalar object payloads are either rejected or explicitly allow-listed.

Ask: one engineer-day (bump + audit + test), and a standing rule that security patch releases in this dependency are auto-merged within 7 days rather than batched into a quarterly upgrade.