|
| 1 | +# Basic Security |
| 2 | + |
| 3 | +Dotkernel API provides all necessary tools to implement safe applications, however you will need to manually make use of some of them. |
| 4 | +This section will go over the provided tools and any steps you need to follow in order to use them successfully, as well as a few general considerations. |
| 5 | + |
| 6 | +## User Input Validation |
| 7 | + |
| 8 | +In order to validate user input, Dotkernel API makes use of [laminas/laminas-inputfilter](https://github.com/laminas/laminas-inputfilter). |
| 9 | +It is strongly recommended that custom functionality parsing user input also make use of input filters to validate the data. |
| 10 | + |
| 11 | +## Content Negotiation |
| 12 | + |
| 13 | +Content negotiation in Dotkernel API is done by a middleware configured using the `config/autoload/content-negotiation.global.php` file. |
| 14 | + |
| 15 | +Whenever an endpoint needs custom `Accept` and/or `Content-Type`, make sure that you set them in the above file. |
| 16 | + |
| 17 | +> Read more about [content negotiation](https://www.dotkernel.com/dotkernel-api/content-negotiation-in-dotkernel-rest-api/) and the way it is implemented in [Dotkernel API](../core-features/content-validation.md). |
| 18 | +
|
| 19 | +## Cross-Origin Resource Sharing |
| 20 | + |
| 21 | +Dotkernel API uses [mezzio/mezzio-cors](https://github.com/mezzio/mezzio-cors) to handle CORS details. |
| 22 | +The default configuration, found in `config/autoload/cors.local.php`, makes the application accessible by any origin. |
| 23 | + |
| 24 | +Make sure your application specifies only the required origins when in a production environment. |
| 25 | + |
| 26 | +> This step is described in the [CORS](../tutorials/cors.md) tutorial. |
| 27 | +
|
| 28 | +## Role-Based Access Control |
| 29 | + |
| 30 | +This project makes use of [mezzio/mezzio-authorization-rbac](../core-features/authorization.md) to handle access control. |
| 31 | + |
| 32 | +The default use cases have already been configured, but any custom functionality will require additional configuration to make sure it is protected. |
| 33 | +Update the configuration file of this package (`config/autoload/authorization.global.php`) whenever you add new routes or roles. |
| 34 | + |
| 35 | +## Demo Credentials |
| 36 | + |
| 37 | +Dotkernel API ships with two demo accounts: an admin account ( `admin`) and a user account ( `[email protected]`), |
| 38 | +with public identities and passwords as described in the [token authentication tutorial](https://docs.dotkernel.org/api-documentation/v6/tutorials/token-authentication/). |
| 39 | + |
| 40 | +Make sure to **update** or **remove** these demo accounts in your production environment. |
| 41 | + |
| 42 | +## Error Reporting Endpoint and ErrorReportingTokens |
| 43 | + |
| 44 | +The error reporting endpoint (`/error-report`) is intended to be used by third parties to report errors back to your application. |
| 45 | +This endpoint requires its own token type, namely an `ErrorReportingToken`, that is to be added in the configuration file for every application sending reports. |
| 46 | + |
| 47 | +Since these tokens do not have an expiration date, consider periodically refreshing them manually. |
| 48 | + |
| 49 | +This feature is configured using the `config/autoload/error-handling.global.php` file, under the configured `ErrorReportServiceInterface::class` key. |
| 50 | + |
| 51 | +This file is visible to your VCS by default, so take care not to overwrite tokens locally and commit them to your production environment. |
| 52 | +Additionally, make sure the `ip_whitelist` or `domain_whitelist` keys are set to your desired values, especially when in a production environment. |
| 53 | + |
| 54 | +> Read more about the [error reporting](../core-features/error-reporting.md) feature. |
| 55 | +
|
| 56 | +## OpenAPI Documentation |
| 57 | + |
| 58 | +In order to provide an interactive documentation, Dotkernel API implemented [zircote/swagger-php](https://github.com/zircote/swagger-php). |
| 59 | + |
| 60 | +Make sure **not** to include sensitive data as examples for any of the documented endpoints. |
| 61 | +It is not recommended to enable the documentation in a production environment. |
| 62 | + |
| 63 | +> Read more about the [OpenAPI documentation](../openapi/introduction.md). |
| 64 | +
|
| 65 | +## PHP Dependencies |
| 66 | + |
| 67 | +Dotkernel API uses `composer` to handle PHP dependencies. |
| 68 | +In time, make sure to review any common vulnerabilities and exposures for your dependencies. |
| 69 | + |
| 70 | +> You may also keep an eye on the Dotkernel API changelog for any updates relevant to your project. |
| 71 | +
|
| 72 | +## General Considerations |
| 73 | + |
| 74 | +- `*.global.php` and `*.php.dist` configuration files are visible to the VCS, make sure **not** to include sensitive data in commits. |
| 75 | + - `*.local.php` configuration files are ignored by the VCS by default and are the recommended place for sensitive data such as API keys. |
| 76 | +- Make sure the `development mode` is correctly set - **do not** enable `development mode` in a production environment. |
| 77 | + - You can use the following command to check the current status: |
| 78 | + |
| 79 | +```shell |
| 80 | +composer development-status |
| 81 | +``` |
| 82 | + |
| 83 | +- Dotkernel API ships with a [Laminas Continuous Integration](https://github.com/laminas/laminas-continuous-integration-action) GitHub Action, |
| 84 | + if you are using a public repository consider keeping it in your custom applications to ensure code quality. |
| 85 | + |
| 86 | +> Read more about using [Laminas Continuous Integration](https://getlaminas.org/blog/2024-08-05-using-laminas-continuous-integration.html). |
0 commit comments