This sample shows a recommended approach to security, as is important for both server side rendered and full stack applications. Although the sample is written in EJS, the security issues and approach also apply to full stack applications.
Here is the link to the EJS project sample.
https://github.com/Code-the-Dream-School/sample-ejs-project
The code can be reused in your final project, but follow the guidelines in your rubric. Although this sample is written in EJS, there are some elements, particularly for security, that are of use to full stack developers as well. This project reuses the models from the Jobs API lesson, with a change to password validation. The project has a modest amount of styling, but careful attention to security. Here are some things to note:
- The xss-clean package is strongly recommended for both back end and server side rendered applications.
- Some students are having trouble configuring Helmet. Look at the example in app.js. It adds the URLs for Bootstrap. It also adds the unsafe-inline directives. These are needed, especially for Bootstrap, but so long as the sources are trusted, they don’t create much of a security risk. It also adds upgradeInsecureRequests: null. This is so that SSL is not used for fetch operations, which would otherwise cause application failures in development mode. Front ends that are served by Express should use Helmet, so this is not only for server side rendering. If your front end is not served by Express, you still need a way to configure HTTP headers so that your application is secure. The Render.com dashboard provides a way to do this, if your front end is served as a static application. This would apply to React applications not served by Express.
- The password attribute in the User model has a required regular expression. This is to prevent trivial passwords. This approach is a little controversial, because it doesn’t protect against all dangerous passwords, and because it does make the user enter a password of a special format. It is very important to avoid trivial passwords if an application is to be secure.
- It would be a good idea to add a Captcha to the registration form.
- The session cookie configuration shows a good model for keeping sessions secure.
- One can add JavaScript to the pages of server side rendered applications to do front end validation of user input. Front end validation is a good idea, although not implemented in this example. Front end validation, both for server side rendered applications and front end applications, does not suffice! You need to have validation in the models too, and in some cases in the controllers.
- A bad practice for server side rendered applications is to do delete operations with a link. This is bad because links should never do write operations. For one thing, cross site request forgery is very easy for links. So JavaScript is added to the page to do the delete. Take a look at the example. It shows how to send the fetch() for delete. The server side then does a redirect, which must be handled in the client side JavaScript following the fetch() call.
- There is protection against cross site request forgery (CSRF). The standard NPM package to provide this protection was CSURF. However, security vulnerabilities were discovered in that package, so it has been withdrawn. Cross site request forgery protection is very important for any application that displays forms delivered from the server side. It does require that a hidden field be added to each form. Check out the EJS pages in this project. As CSURF is no longer available, I created an alternative, which you could add to your project. See the CSRF methods in middleware/auth. Note that the CSRF token is refreshed at logon time. This approach is only secure if the session itself is secure, which is not true if the session values are held in a cookie. In this example, session values are stored in the Mongo database.
