config cds.server.body_parser.limit (and cds.server config section)

guides/security/aspects.md

@@ -520,6 +520,8 @@ Additional size limits and timeouts (request timeout) are established by the rev
 
 ::: tip
 If you want to apply an application-specific sizing, consult the corresponding framework documentation.
+
+See section [Maximum Request Body Size](../../node.js/cds-server#maximum-request-body-size) to find out how to restrict incoming requests to a CAP Node.js application depending on the body size.
 :::
 
 Moreover, CAP adapters automatically introduce query results pagination in order to limit memory peaks (customize with [`@cds.query.limit`](../providing-services#annotation-cds-query-limit)).

node.js/cds-server.md

@@ -113,7 +113,7 @@ cds.on('served', ...)
 ### Override `cds.server()`
 
 Provide an own bootstrapping function if you want to access and process the command line options.
-This also allows you to override certain options before delegating to the built-in server.js.
+This also allows you to override certain options before delegating to the built-in `server.js`.
 In the example below, we construct the express.js app ourselves and fix the models to be loaded.
 
 ```js
@@ -213,7 +213,7 @@ In other words this asynchronous handler code does **not work** as expected:
 ```js
 cds.on ('bootstrap', async ()=> {
   await asyncCode() // [!code error] // will NOT be awaited
-}
+})
 ```
 
 You can use the [served](#served) event's asynchronous nature though to wait for such bootstrap code:
@@ -222,14 +222,63 @@ You can use the [served](#served) event's asynchronous nature though to wait for
 let done
 cds.on('bootstrap', ()=> {
   done = asyncCode()
-}
+})
 cds.on('served', async ()=> {
   await moreCode()
   await done
 })
 ```
 
 
+
+## Configuration
+
+The behavior of the built-in `server.js` can be customized through the options documented in the following sections.
+
+### CORS Middleware
+
+The built-in CORS middleware can be enabled explicitly with `cds.server.cors = true`.  By default, this is `false` if in production.
+
+[Learn more about best practices regarding **Cross-Origin Resource Sharing (CORS)**.](../node.js/best-practices.md#cross-origin-resource-sharing-cors) {.learn-more}
+
+
+
+### Toggle Generic Index Page
+
+The default generic _index.html_ page is not served if `NODE_ENV` is set to `production`. Set `cds.server.index = true` to restore the generic index page in production.
+
+[See the **Generic *index.html*** page in action.](../get-started/in-a-nutshell.md#generic-index-html) {.learn-more}
+
+
+
+### Maximum Request Body Size
+
+There are two ways to restrict the maximum request body size of incoming requests, globally for all endpoints and for individual services. If the payload exceeds the configured value, the request is rejected with _413 - Payload too large_. The configured values are passed through to the underlying Express body parser middlewares. Therefore, the default limit is _100kb_, as this is the default of the Express built-in [body parsers](https://expressjs.com/en/api.html#express.json).
+
+The maximum request body size can be limited globally, for all services and protocols, using the configuration `cds.server.body_parser.limit`, like so:
+
+```jsonc
+{
+  "cds": {
+    "server": {
+      "body_parser": {
+        "limit": "1mb" // also accepts b, kb, etc...
+      }
+    }
+  }
+}
+```
+
+To restrict the maximum request body size of requests received by an individual service, the service specific annotation `@cds.server.body_parser.limit` can be used, like so:
+
+```cds
+annotate AdminService with @cds.server.body_parser.limit: '1mb';
+```
+
+This is useful when the expected request body sizes might vary for services within the application. If both the global configuration and the service specific annotation are set, the service specific annotation takes precedence for the respective service.
+
+
+
 ## See Also...
 
 The [`cds-plugin` package technique](cds-plugins) provides more options to customize server startup.