Weave Code
Laravel Encryptable Laravel Package
h-farm/laravel-encryptable
Transparently encrypt Eloquent model attributes at rest with a simple trait. Values are encrypted on save and decrypted on read, so your code keeps working with plain strings while the database stores only ciphertext. A drop-in Laravel package that's easy to configure.
Easily anonymize sensitive data through eloquent queries
Frequently asked questions about Laravel Encryptable
- How do I install h-farm/laravel-encryptable in a Laravel app?
- Run composer require h-farm/laravel-encryptable, then add the package trait to any Eloquent model and declare an $encryptable array listing the attributes you want protected. There is no service provider registration, no config publishing, and no migration required. The trait intercepts attribute get and set calls so values are encrypted with Laravel's Crypt on write and decrypted transparently on read.
- Which Laravel and PHP versions does this package support?
- Release 4.1.0 adds support for Laravel 13 and PHP 8.5, which keeps the package viable on a forward framework and PHP upgrade path. It is a minor release from 4.0.0, so no breaking API changes are implied by semver, but you should verify that against the actual diff. Always check the illuminate/support and php constraints in the package composer.json before upgrading your application.
- How do I configure which model attributes get encrypted?
- Encryption is opt-in per model: use the trait and set a protected $encryptable array containing the column names. Everything else stays normal Eloquent behavior, with no casts file, schema change, or config file needed. You can still define accessors and mutators, but remember they will receive already-decrypted values.
- Can I use where, orderBy, or unique indexes on encrypted columns?
- No. The package produces non-deterministic ciphertext, so where() clauses, LIKE searches, ORDER BY, GROUP BY, aggregates, and UNIQUE constraints on encrypted columns stop behaving as expected and often silently return no rows instead of throwing an error. If a product requirement needs equality lookups, add your own blind index column (a deterministic HMAC of the value) and query that instead. Treat encrypted columns as display-only fields.
- What happens if I rotate APP_KEY with encrypted data in the database?
- Ciphertext is bound to APP_KEY, or to a configured custom key, so rotating the key without re-encrypting the data permanently destroys it. Write a documented runbook: decrypt with the old key and re-encrypt with the new one inside a migration or artisan command, then swap keys. A dedicated encryption key separate from APP_KEY is strongly recommended for production.
- What column type and length should I use for encrypted attributes?
- Ciphertext plus the IV, authentication tag, and base64 encoding is materially longer than the plaintext, so VARCHAR(255) columns that fit today may truncate. Use TEXT or generously sized VARCHAR columns sized against your worst-case field content. Test with realistic maximum-length values before deploying to production.
- How do I test encrypted attributes with PHPUnit or Pest?
- Use RefreshDatabase as usual, create the model with plaintext values, and assert that your application reads back the original strings. To verify encryption actually happened, query the raw column with the query builder or DB facade and assert it does not equal the plaintext, optionally decrypting it with Crypt::decryptString. Do not assert exact ciphertext, because encryption is non-deterministic and every save produces different output.
- Does encryption leak plaintext through toArray, toJson, logs, or queues?
- Yes, by design. Decryption is transparent, so toArray(), toJson(), log context, queued job payloads, and Nova, Filament, or Livewire bindings all contain plaintext once the model is hydrated. Handle this explicitly with $hidden, log scrubbing, and careful serialization. Treat every code path that reads the model as a plaintext exposure path.
- How do I migrate existing plaintext rows to encrypted columns?
- The package only encrypts on write, so you need a backfill. Read existing rows and re-save them through the model, or write a one-off command that encrypts values in place using Laravel's Crypt facade, then enable the trait. Use a maintenance window or dual-write approach to avoid a mixed plaintext and ciphertext window if the column must stay readable throughout.
- How does this compare to database TDE, and is the package well maintained?
- This is application-side, column-level encryption: only the Laravel model can read the values, and anyone with raw database access or a BI tool sees ciphertext, so it complements rather than replaces TLS in transit, database TDE at rest, and a KMS. It does not protect against an attacker who has your APP_KEY or code execution. The package is small with a single maintainer and a narrow dependency surface, so pin versions and isolate trait usage behind your own base model or wrapper to keep a fork cheap; Laravel's built-in encrypted casts and CipherSweet are the common alternatives.
Weaver
How can I help you explore Laravel packages today?