tabshift/payloadcms
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

docs: preventing abuse of file uploads

Browse Source
This commit is contained in:
Dan Ribbens
2022-04-29 23:25:55 -04:00
parent e7349fea9a
commit 738e8ab9b6
2 changed files with 20 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/fields/overview.mdx
View File

@@ -251,14 +251,14 @@ const field = {
type: 'text',
admin: {
// highlight-start
description: ({ user, locale }) => (`${translation[locale]} ${user.name}`)
defaultValue: ({ user, locale }) => (`${translation[locale]} ${user.name}`)
// highlight-end
}
};
```
<Banner type="success">
`defaultValue` also supports `async` functions allowing requests to be made to populate field data from a query.
You can use async defaultValue functions to fill fields with data from API requests.
</Banner>
### Description
@@ -280,7 +280,8 @@ As shown above, you can simply provide a string that will show by the field, but
type: 'text',
maxLength: 20,
admin: {
description: ({ value }) => (`${typeof value === 'string' ? 20 - value.length : '20'} characters left`)
description: ({ value }) =>
(`${typeof value === 'string' ? 20 - value.length : '20'} characters left`)
}
}
]

21
docs/production/preventing-abuse.mdx
View File

@@ -10,11 +10,11 @@ keywords: abuse, production, config, configuration, documentation, Content Manag
Payload has built-in security best practices that can be configured to your application-specific needs.
#### Limit Failed Login Attempts
### Limit Failed Login Attempts
Set the max number of failed login attempts before a user account is locked out for a period of time. Set the `maxLoginAttempts` on the collections that feature Authentication to a reasonable but low number for your users to get in. Use the `lockTime` to set a number in milliseconds from the time a user fails their last allowed attempt that a user must wait to try again.
#### Rate Limiting Requests
### Rate Limiting Requests
To prevent DDoS, brute-force, and similar attacks, you can set IP-based rate limits so that once a certain threshold of requests has been hit by a single IP, further requests from the same IP will be ignored. The Payload config `rateLimit` property accepts an object with the following properties:
@@ -30,21 +30,32 @@ To prevent DDoS, brute-force, and similar attacks, you can set IP-based rate lim
Very commonly, NodeJS apps are served behind `nginx` reverse proxies and similar. If you use rate-limiting while you're behind a proxy, <strong>all</strong> IP addresses from everyone that uses your API will appear as if they are from a local origin (127.0.0.1), and your users will get rate-limited very quickly without cause. If you plan to host your app behind a proxy, make sure you set <strong>trustProxy</strong> to <strong>true</strong>.
</Banner>
#### Max Depth
### Max Depth
Querying a collection and automatically including related documents via `depth` incurs a performance cost. Also, it's possible that your configs may have circular relationships, meaning scenarios where an infinite amount of relationships might populate back and forth until your server times out and crashes. You can prevent any potential of depth-related issues by setting a `maxDepth` property on your Payload config.. The maximum allowed depth should be as small as possible without interrupting dev experience, and it defaults to `10`.
#### Cross-Site Request Forgery (CSRF)
### Cross-Site Request Forgery (CSRF)
CSRF prevention will verify the authenticity of each request to your API to prevent a malicious action from another site from authorized users. See how to configure CSRF [here](/docs/authentication/overview#csrf-protection).
#### Cross Origin Resource Sharing (CORS)
### Cross Origin Resource Sharing (CORS)
To securely allow headless operation you will need to configure the allowed origins for requests to be able to use the Payload API. You can see how to set CORS as well as other payload configuration settings [here](/docs/configuration/overview)
### Limiting GraphQL Complexity
Because GraphQL gives the power of query writing outside a server's control, someone with bad intentions might write a maliciously complex query and bog down your server. To prevent resource-intensive GraphQL requests, Payload provides a way specify complexity limits which are based on a complexity score that is calculated for each request.
Any GraphQL request that is calculated to be too expensive is rejected. On the Payload config, in `graphQL` you can set the `maxComplexity` value as an integer. For reference, the default complexity value for each added field is 1, and all `relationship` and `upload` fields are assigned a value of 10.
If you do not need GraphQL it is advised that you disable it altogether with the Payload config by setting `graphQL.disable: true`. Should you wish to enable GraphQL again, you can remove this property or set it `false`, any time. By turning it off, Payload will bypass creating schemas from your collections and will not register the express route.
### Malicious File Uploads
Payload does not execute uploaded files on the server, but depending on your setup it may be used to transmit and store potentially dangerous files. If your configuration allows file uploads there is the potential that a bad actor uploads a malicious file that is then served to other users. Consider the following ways to mitigate the risks.
First, enable email [verification](/docs/authentication/config#email-verification) when users are allowed to register new accounts and add other bot prevention services.
Review that `create` and `update` access on file upload collections are as restrictive as your application needs allow. Consider limiting `read` access of uploaded user's files and how you might limit user uploaded files from being served outside of Payload.
You can also add a [3rd party library](https://www.npmjs.com/package/clamscan) to scan files in a [hook](/docs/hooks/collections) or have antivirus software in place.