SECURITY.md: add section with coding practices

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>

SECURITY.md

@@ -36,3 +36,34 @@ There are many situations where a vulnerability does not affect a particular dep
 To work around this and other similar issues, Snyk provides a method to ignore vulnerabilities. In order to provide the best visibility and most utility to adopters of Backstage, we store these ignore rules in `.snyk` policy files. This allows adopters to rely on our ignore policies if they wish to do so.
 
 Adding a new ignore policy is done by creating or modifying an existing `.snyk` file within a package root. See the [Snyk Documentation](https://support.snyk.io/hc/en-us/articles/360007487097-The-snyk-file) for details on the syntax. Always include a description, full path, and time limit of the ignore policy.
+
+## Coding Practices
+
+In this section we highlight patterns where particular care needs to be taken in order to avoid security vulnerabilities, as well as the best practices to follow.
+
+### Local file path resolution
+
+A common pitfall in backend packages is to resolve local file paths based on user input, without sufficiently protecting against input that traverses outside the intended directory.
+
+For example, consider the following code:
+
+```ts
+import { join } from 'path';
+import fs from 'fs-extra';
+
+function writeTemporaryFile(tmpDir: string, name: string, content: string) {
+  // WARNING: DO NOT DO THIS
+  const filePath = join(tmpDir, name);
+  await fs.writeFile(filePath, content);
+}
+```
+
+If the `name` of the file is controlled by the user, they can for example enter `../../../../../../../../etc/hosts` as the name of the file. This can lead to a file being written outside the intended directory, which in turn can be used to inject malicious code or other form of attacks.
+
+The recommended solution to this is to use `resolveSafeChildPath` from `@backstage/backend-common` to resolve the file path instead. It makes sure that the resolved path does not fall outside the provided directory. If you simply what to validate whether a file path is safe, you can use `isChildPath` instead.
+
+### Express responses
+
+When returning a response from an Express route, always use `.json(...)` or `.end()` without any arguments. This ensures that the response can not be interpreted as an HTML document with embedded JavaScript by the browser. Never use `.send(...)` unless you want to send other forms of content, and be sure to always set an explicit content type. If you need to return HTML or other content that may be executed by the browser, be very careful how you handle user input.
+
+If you want to return an error response, simply throw the error or pass it on to the `next(...)` callback. There is a middleware installed that will transform the error into a JSON response. Many of the common HTTP errors are available from `@backstage/errors`, for example `NotFoundError`, which will also set the correct status code.