[Strapi 5] Breaking change for default input validation (#2096)

* Update controllers documentation * Create breaking change entry

Author: pwizla

docusaurus/docs/dev-docs/backend-customization/controllers.md

@@ -225,6 +225,17 @@ To see a possible advanced usage for custom controllers, read the [services and
 It's strongly recommended you sanitize (v4.8.0+) and/or validate (v4.13.0+) your incoming request query utilizing the new `sanitizeQuery` and `validateQuery` functions to prevent the leaking of private data.
 :::
 
+Sanitization means that the object is “cleaned” and returned.
+
+Validation means an assertion is made that the data is already clean and throws an error if something is found that shouldn't be there.
+
+In Strapi 5, both query parameters and input data (i.e., create and update body data) are validated. Any create and update data requests with the following invalid input will throw a `400 Bad Request` error:
+
+- relations the user do not have permission to create
+- unrecognized values that are not present on a schema
+- non-writable fields and internal timestamps like `createdAt` and `createdBy` fields
+- the `id` field (other than for connecting relations) which attempts to set or update the `id` of an object
+
 #### Sanitization when utilizing controller factories
 
 Within the Strapi factories the following functions are exposed that can be used for sanitization and validation:

docusaurus/docs/dev-docs/migration/v4-to-v5/breaking-changes.md

@@ -39,6 +39,7 @@ This page lists all the breaking changes introduced in Strapi 5.
 <!-- * [Components and dynamic zones do not return an `id` with REST API requests](/dev-docs/migration/v4-to-v5/breaking-changes/components-and-dynamic-zones-do-not-return-id) not implemented yet -->
 * [The GraphQL API has been updated](/dev-docs/migration/v4-to-v5/breaking-changes/graphql-api-updated)
 * [The Entity Service API is deprecated and replaced by the Document Service API](/dev-docs/migration/v4-to-v5/breaking-changes/entity-service-deprecated)
+* [REST API input is validated by default in controllers](/dev-docs/migration/v4-to-v5/breaking-changes/default-input-validation)
 
 ## Database
 

docusaurus/docs/dev-docs/migration/v4-to-v5/breaking-changes/default-input-validation.md

@@ -0,0 +1,69 @@
+---
+title: REST API input is validated by default in controllers
+description: In Strapi 5, REST API input is validated by default in controllers, instead of accepting invalid data and sanitizing it silently.
+sidebar_label: Default input validation
+displayed_sidebar: devDocsMigrationV5Sidebar
+tags:
+ - breaking changes
+ - controllers
+ - validation
+---
+
+import Intro from '/docs/snippets/breaking-change-page-intro.md'
+import MigrationIntro from '/docs/snippets/breaking-change-page-migration-intro.md'
+import YesPlugins from '/docs/snippets/breaking-change-affecting-plugins.md'
+import NoCodemods from '/docs/snippets/breaking-change-not-handled-by-codemod.md'
+
+# REST API input is validated by default in controllers
+
+Sanitization means that the object is “cleaned” and returned.
+
+Validation means an assertion is made that the data is already clean and throws an error if something is found that shouldn't be there.
+
+Strapi methods exist both for [sanitization and validation in controllers](/dev-docs/backend-customization/controllers#sanitization-and-validation-in-controllers) and they can target input body data, query parameters, and output (only for sanitization).
+
+In Strapi 5, REST API input is validated by default in controllers, instead of accepting invalid data and sanitizing it silently.
+
+<Intro />
+
+<YesPlugins />
+<NoCodemods />
+
+## Breaking change description
+
+<SideBySideContainer>
+
+<SideBySideColumn>
+
+**In Strapi v4**
+
+In v4, query parameters are validated, but input data (create and update body data) is only sanitized.
+
+</SideBySideColumn>
+
+<SideBySideColumn>
+
+**In Strapi 5**
+
+In v5, both query parameters and input data are validated.
+
+</SideBySideColumn>
+
+</SideBySideContainer>
+
+## Migration
+
+<MigrationIntro />
+
+### Notes
+
+* A `400 Bad Request` error will be thrown if the request has invalid values such as in in the following cases:
+
+ - relations the user do not have permission to create
+ - unrecognized values that are not present on a schema
+ - attempt to writing non-writable fields and internal timestamps like `createdAt` and `createdBy` fields
+ - usage of the `id` field (other than for connecting relations) to set or update the `id` of an object
+
+### Manual procedure
+
+Users should ensure that parameters and input data are valid to avoid `400` errors being thrown. Additional information can be found in the [sanitization and validation in controllers](/dev-docs/backend-customization/controllers#sanitization-and-validation-in-controllers) documentation.

docusaurus/sidebars.js

@@ -1158,6 +1158,7 @@ const sidebars = {
  // 'dev-docs/migration/v4-to-v5/breaking-changes/components-and-dynamic-zones-do-not-return-id', // not implemented yet
  'dev-docs/migration/v4-to-v5/breaking-changes/graphql-api-updated',
  'dev-docs/migration/v4-to-v5/breaking-changes/entity-service-deprecated',
+ 'dev-docs/migration/v4-to-v5/breaking-changes/default-input-validation',
  ]
  },
  {