How to store user data client side

Jonatan — Sun, 28 May 2023 11:41:57 +0000

Modern web applications often store and display user data in the browser to personalize the user experience. This might include non-sensitive data, such as user preferences or UI state, and sensitive data, like usernames or email addresses. Data can be stored in various ways, including in cookies, LocalStorage, SessionStorage, or IndexedDB. However, storing sensitive data in the browser will open your application to security risks, such as Cross-Site Scripting (XSS) attacks.

Cross-Site Scripting (XSS) TL;DR

Cross-Site Scripting (XSS) is a web security vulnerability that allows attackers to inject malicious scripts into web pages, exploiting unvalidated or improperly escaped user input. These scripts can steal sensitive information or perform actions on behalf of the user, posing serious security risks.

What you should do TL;DR

The more persistent your user information storage is the more susceptible to XSS attacks your application is. Therefore, the most secure approach is to refrain from storing any sensitive user information in the client-side. However, if user data storage is inevitable, the most secure approach is to fetch it on-demand, using it only when necessary, and avoiding persisting this information across pages. This practice significantly mitigates potential risks, ensuring a safer user experience and a more secure application.

If you absolutely have to store user information in the browser here are a few options organized by more susceptible to XSS and less susceptible to XSS.

Less XSS vulnerable options

Fetch user information when needed

Once the user logs in, you can make an API request to fetch the user's profile information, including their email.
You will need to re-fetch this information when the user reloads the page. But if you only request the information when needed, malicious scripts have a smaller attack vector.
If you store this information in the application's state your attack vector increases, but will be smaller than in the more persistent storage options explained below.

More XSS vulnerable options

Store the email in a non-HTTP-only secure cookie

You can store the email in a cookie that isn't set to HTTP-only. This would make it accessible to JavaScript through the document.cookie API. Cookies also persist across page refreshes. But, like LocalStorage, cookies are also vulnerable to XSS attacks.

Use the Session or Local Storage

On successful login, you can store the user's email in the Session Storage or Local Storage. The email can then be retrieved and displayed whenever necessary. However, as discussed in previous responses, this approach has some security risks.

Embed the email in the token (JWT)

You can include the email in the payload of the JSON Web Token (JWT) that is sent to the client after a successful login. The frontend can decode the token and extract the email to display it. However, be aware that the information in a JWT is not encrypted, only encoded.

Embed in the page HTML

When the server generates the HTML for the page, it can embed the user's email directly into the script. This can be a good option if your server renders your pages, but it won't work if your frontend is a single-page application that doesn't regularly receive full page updates from the server.

In conclusion, no matter how you go about it storing user data on the client side will open up your application to security risks, such as XSS attacks. The principle of reducing attack vectors guides us towards best practices: it's safest not to store any sensitive user information client-side if possible. If storage of user data is essential, minimizing persistence and fetching data on-demand is the recommended approach.

Remember to ensure you're complying with all relevant privacy laws and regulations when handling user data.

How to deploy a Django App on Heroku in less than 5 minutes

Jonatan — Sat, 02 Oct 2021 19:05:42 +0000

In this short tutorial, I will demonstrate how to deploy a Django project on Heroku while serving static files from your own domain.

Prerequisites:

python (https://www.python.org/downloads/)
Django (https://docs.djangoproject.com/en/3.2/topics/install/)
virtualenv (https://virtualenv.pypa.io/en/latest/installation.html)
pip (https://pip.pypa.io/en/stable/installation/)
heroku-cli (https://devcenter.heroku.com/articles/heroku-cli)

You do not need to use virtualenv, but it is highly recommended to use an isolated environment for different projects. Another option to virtualenv, for deploying to Heroku, is pipenv.

Installing Django, virtualenv, pip and the heroku-cli on Ubuntu

sudo apt install python3
sudo apt install python3-django
sudo apt install python3-virtualenv
sudo apt install python3-pip
sudo snap install --classic heroku

Creating a Django project

We can now create our Django project named myproject

django-admin startproject myproject

Setting up your virtual environment

You now want to go to the root of your project and set up your virtual environment.

Navigate to your project

cd myproject

Make a virtual environment

virtualenv venv

Activate your virtual environment

source venv/bin/activate

Install Django in your virtual environment

pip install django

Creating a new Heroku project

We now want to create a new Heroku project.

heroku create

This will create a domain at https://example.herokuapp.com so select the project name to be the domain you want your project to be hosted at. (You can later add a custom domain).

Changing the secret key

First, we want to change the SECRET_KEY to an environment variable, because we want to have a unique SECRET_KEY in production that we don't push to version control.

SECRET_KEY = os.getenv('SECRET_KEY', 'change-in-production')

Now we can set our production environment variable with

heroku config:set SECRET_KEY=very-long-secret-key

We now need to set up static files and turn off DEBUG mode in production.

Setting up static files

We are going to use whitenoise to serve static files. First, we need to install it

pip install whitenoise

Next, we add the whitenoise middleware to the top of the middleware section

MIDDLEWARE = [
    'whitenoise.middleware.WhiteNoiseMiddleware', # First in list
    ...
]

Next, we set up the path of our static files

STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static')

We then install django_heroku to configure default values.

pip install django_heroku

We enable the django_heroku settings, but set staticfiles and allowed_hosts to False, because we want to specify our own static file options and change allowed_hosts from the django_heroku default value ['*'] to prevent Host Header attacks.

django_heroku.settings(locals(), staticfiles=False, allowed_hosts=False)

At the bottom of the settings.py file, we will now add settings specific to Heroku.

if "DYNO" in os.environ:
    STATIC_ROOT = 'static'

Initializing git

We will now add git to our project.

git init

Adding Heroku to your git remotes

heroku git:remote -a example

Disabling DEBUG and settings allowed hosts

We now want to disable DEBUG in production and add our domain to our allowed hosts. We add these options in the if "DYNO" in os.environ block because we only want these settings to be in effect in production.

if "DYNO" in os.environ:
    STATIC_ROOT = 'static'
    ALLOWED_HOSTS = ['example.herokuapp.com']
    DEBUG = False

Adding the Procfile

First, we will add the Procfile. To do this just add a file called Procfile (without any extension) to the root of your project. On ubuntu and mac simply write

touch Procfile

We then install gunicorn which is the HTTP server we use in production on Heroku.

pip install gunicorn

while in the terminal while in the root directory. Next, add the following to the file

web: gunicorn myproject.wsgi --log-file -

Adding the requirements.txt file

Our last step is to create the requirements.txt file, which will specify all the packages that we have used. Since we used a virtual environment, this step is very easy. All we have to do is type

pip freeze > requirements.txt

in the terminal while being in our projects root directory. This will add all our packages installed through pip to the requirements.txt file automatically.

If you weren't using a virtual environment, you can also manually create a requirements.txt file in the root directory and manually add all the requirements. If you did everything correctly your requirements.txt file should look like

asgiref==3.4.1
dj-database-url==0.5.0
Django==3.2.7
django-heroku==0.3.1
gunicorn==20.1.0
psycopg2==2.9.1
pytz==2021.1
sqlparse==0.4.2
whitenoise==5.3.0

Deploying to Heroku

We are now ready to deploy our project.

git add .
git commit -m "My first project is ready to be deplayed"
git push heroku main

And we are done! Your project is now deployed to Heroku.

Optional settings for production

If you want to make sure your project only works over https you want to add the following options to your production settings.

if "DYNO" in os.environ:
    STATIC_ROOT = 'static'
    ALLOWED_HOSTS = ['example.herokuapp.com']
    DEBUG = False
    SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
    SECURE_SSL_REDIRECT = True
    SESSION_COOKIE_SECURE = True
    CSRF_COOKIE_SECURE = True

CSRF_COOKIE_SECURE - Ensures your CSRF cookies will be served over https.
SESSION_COOKIE_SECURE - Ensures your session cookies will be served over https.
SECURE_PROXY_SSL_HEADER & SECURE_SSL_REDIRECT - Will redirect all HTTP traffic to https

DEV Community: Jonatan