Fix CakePHP Mass‑Assignment Misconfigurations

When CakePHP’s mass‑assignment protection is misconfigured, sensitive fields can be written to the database. This guide walks through diagnosing the problem, checking <code>$accessible</code> arrays, testing protection, and applying fixes so that only intended data is persisted.

Problem Statement

In CakePHP, the mass‑assignment protection mechanism prevents arbitrary data from being written to entity fields that should remain immutable (e.g., id, role_id, password_hash). When this protection is disabled globally, incorrectly defined $accessible arrays, or legacy code that mixes $dirty and $accessible, unintended data can be persisted, creating a serious security risk.

Recognizable Condition

During a security audit you discover that user‑submitted data is being written to fields that should be read‑only. Typical symptoms include:

Admin‑level fields changing after a normal user request.
Unexpected values in the database that match the payload sent by the client.
Unit tests that pass when the field is present in the request but fail when removed.

Short Cause/Diagnostic Table

Cause	Diagnostic Indicator	Typical Fix
Mass‑assignment protection disabled globally	All entity fields show as writable in the debugger.	Re‑enable `Entity::setAccessible()` defaults or remove `Entity::newEntity($data, ['accessibleFields' => true])`.
Incorrect `$accessible` array	Sensitive fields appear with `true` in `$accessible` or are missing.	Explicitly set `false` for protected fields.
Legacy code overriding defaults	Calls to `newEntity()` without specifying `accessibleFields` in CakePHP 5.	Specify `['accessibleFields' => false]` or use `Entity::newEntity($data, ['accessibleFields' => ['field1' => true]])`.
Mixing `$dirty` and `$accessible`	Fields become writable when `$dirty` is set programmatically.	Avoid setting `$dirty` on protected fields; use `setProperty()` with an accessible check.

Ordered Checks

Verify Global Protection
Open src/Entity/Entity.php (or the equivalent in your CakePHP version) and confirm that Entity::setAccessible() is not overridden to allow all fields. Look for a line like:
```
Entity::setAccessible(["*" => true]);
```
If present, comment it out or change it to Entity::setAccessible(["*" => false]);.
Inspect Model Entity $accessible
Navigate to src/Model/Entity/YourEntity.php and locate the protected $accessible array. Ensure sensitive fields are set to false:
```
protected $accessible = [
    "id" => false,
    "role_id" => false,
    "password_hash" => false,
    "*" => true, // only safe fields
];
```
Check Table Methods for Overrides
Search src/Model/Table/YourTable.php for any usage of newEntity() or patchEntity() that passes ['accessibleFields' => true] or ['accessibleFields' => false]. Example:
```
$entity = $this->newEntity($data, ["accessibleFields" => true]);
```
Replace with:
```
$entity = $this->newEntity($data, ["accessibleFields" => ["name" => true, "email" => true]]);
```

Run a Unit Test for Protected Field Write

Create a quick test to confirm protection. In tests/TestCase/Model/Table/YourTableTest.php add:

public function testProtectedFieldNotPersisted() {
    $table = TableRegistry::getTableLocator()->get('Users');
    $data = ["id" => 1, "role_id" => 5, "username" => "alice"]; // role_id is protected
    $entity = $table->newEntity($data);
    $this->assertNull($entity->role_id, "Protected field should be null");
}

Run with vendor/bin/phpunit tests/TestCase/Model/Table/YourTableTest.php.

Audit Database State After Request
Use a debugging tool or log the SQL before execution:
```
$query = $table->save($entity, ["checkAccessible" => true]);
    debug($entity->getDirty()); // should list only expected fields
```
Confirm that protected fields do not appear in the dirty list.

Fixes Tied to Findings

Global protection disabled: Re‑enable defaults or remove the override.
Incorrect $accessible: Explicitly set false for each sensitive field.
Legacy overrides: Replace accessibleFields => true with a whitelist or remove the option entirely.
Mixing $dirty and $accessible: Use Entity::setProperty() with a guard check, or avoid setting $dirty on protected fields.

Escalation Criteria

If, after applying the above fixes, you still observe unintended persistence:

Check for custom behaviors or plugins that modify entity hydration.
Enable CakePHP debug mode (Configure::write('debug', 2);) and inspect the debug() output of the entity before save().
Review the database triggers or stored procedures that might alter data after insert.
If the issue persists in production but not in staging, compare the app.php and app_local.php configuration files for differences in Security.salt or Security.cipherSeed that could affect hashing.

Limitations and Practical Checks

Mass‑assignment rules changed in CakePHP 5.0; legacy applications may rely on the old defaults. Verify the version with bin/cake --version.
Disabling protection for tests can mask real issues. Ensure that the app_test.php configuration re‑enables protection before running integration tests.
Unit tests confirm that protected fields are not set in the entity, but they do not guarantee that the ORM will not persist them if the developer bypasses newEntity() and writes directly to the database. Review any custom repository code for direct SQL usage.

Conclusion

By systematically inspecting the global settings, entity $accessible arrays, table method overrides, and running targeted unit tests, you can reliably detect and fix mass‑assignment misconfigurations in CakePHP. This protects sensitive fields from accidental or malicious writes and aligns your application with CakePHP’s security best practices.

Diagnosing CakePHP Mass‑Assignment Misconfigurations: A Step‑by‑Step Guide