Strong Parameters and mass assignment

Direct Answer

Strong Parameters require controller input to be explicitly permitted before Active Model mass assignment. Use params.expect in current Rails or require(...).permit(...) in established code to select the allowed shape, but still validate values and authorize which fields this particular user may change.

Deep Dive & Architecture

Rails collects query, body, and route data into an ActionController::Parameters object. It is intentionally marked unpermitted. Passing a nested unpermitted parameters object to Model.create or record.update raises ActiveModel::ForbiddenAttributesError; modern Rails does not simply assign every submitted column. This fail-closed behaviour is the foundation of Strong Parameters.

expect is the concise current API for requiring and permitting an expected shape. params.expect(user: [:name, :email]) requires user to be a suitable nested parameters hash and returns permitted values for the listed fields. The familiar require(:user).permit(:name, :email) remains widespread. Missing or malformed required structure is handled as a bad request rather than becoming a mysterious nil later.

Nested data needs an exact declaration. A scalar list uses an empty array marker, while nested objects list their own allowed keys. Permitting an empty hash accepts arbitrary keys and can automatically expose future model attributes, so it is not a shortcut for a schema that the application actually knows. permit! and to_unsafe_h similarly bypass the boundary and should be rare and reviewed.

The permitted list is endpoint-specific, not model-wide. A self-service update might permit display name and time zone; an administrator action might also permit suspension state after a separate policy check. Putting :admin in a shared user_params method would make mass assignment technically allowed even when the current caller has no authority. Strong Parameters cannot infer that business rule.

After filtering, model validations enforce type and domain constraints, database constraints protect persisted invariants, and authorization checks the actor and record. Request specs should submit an unexpected sensitive field and prove it remains unchanged, test missing and wrongly shaped roots, and cover each role's accepted fields. This makes the boundary observable and protects it when columns or nested forms are added later.

For APIs, distinguish an unknown field from a known field the caller cannot change. The response policy may reject unknown keys or ignore them for compatibility, but a sensitive attempted update should be observable without echoing secrets. Tests should document that decision consistently across endpoints.

Code Example

class UsersController < ApplicationController
  def update
    current_user.update!(profile_params)
    redirect_to profile_path
  end

  private

  def profile_params
    params.expect(user: [:name, :email, :time_zone])
  end
end

# A separate admin controller may permit :suspended after authorization.

The self-service endpoint has no mass-assignment path for admin or suspension fields.

Common Mistakes & Pitfalls

Saying unpermitted params are silently mass-assigned or believing permit(:admin) is safe for every caller.