Confessions of a Django Developer: Mistakes You Must Avoid in Production 🚨

Hey have you ever did the below miskates in production? Let’s dive into some potential mistakes every django developer must not do. I did almost every of the below mistakes in my previous experience😥.

1. Debug = True

Why we should not keep “Debug = True” in production🤔? Please have a look at below images.

Image-1(Debug=True)

Image — 2(Debug = False)

I wantedly made an error in code to explain the difference. In the first image where “Debug=True”, django is tracking every error and displaying all details related to error. If we scroll down there is so much of sensitive data like settings configuration, file storage paths, source code, dependencies etc.

Actually this detailed tracking of errors is for development purpose only to make the debugging easier for developer. But in production this is not a good practice.

2. ALLOWED_HOSTS = [“*”]

Using this in production causes several security threats like host header attacks.

• Attackers will send requests from malicious host headers to server to change the responding behaviour of server.
• Your server will accept any domain or IP, which is not expected in production since your server is intented to handle traffic from specific domains only. Let’ suppose your server can handle some amount of traffic. Now attackers or your competitors😜 will send unwanted concurrent requests from different fake domains to make your server down. Attacker rocks developer shocks😂.
• If developer is using caching for performance and ALLOWED_HOSTS = [“*”] for safely allowing attacks😎, then there is potential risk of caching manipulation as well. Let me explain what it means. For suppose if developer is caching response which contains links using domain for instance “http://<request.get_host()>/all-posts/”, then if genuine user accessing that cache hits that link, will be redirected to that malicious site.

Note:- We will use request.get_host() in django for getting host or domain.

3. Using runserver in production

• python manage.py runserver command is intented for development purpose only because runserver is single threaded.
• It can’t handle concurrent requests which is not suitable for production level traffic.
• Use web servers like “gunicorn” in production which can handle concurrent requests and suitable for production. In case if you are handling two way communication protocols like Websockets consider using Uvicorn, daphne etc since these are (Asynchronous server gateway interface) ASGI servers and can handle both HTTP and Websockets concurrently.

Note:- “gunicorn” can’t handle websockets since it is (Web server gateway interface) WSGI server.

4. Hardcoding everything

• We should not hardcode any configurations in any of our application file. Better to keep them in “.env” file and also use “.gitignore”.

5. Not Authenticating APIs

• At the time of development most of the developers feels lazy🥱 to authenticate apis because while testing it will be easier to directly hit api rather than giving token and changing token everytime it expires. But attackers feel energetic🤑🧐 if they find there is no authentication.
• Potential issues are data breach, data leakage, mishandling of data.

6. Api Rate limiting(Throttling)

• What if I want to down your server because your application is competing with mine? Even though you are following all the above practices I have one more way.
• “I will become an authorized user of your application and starts hitting multiple apis in loop untill your server is down😈. Iam the danger😂”.
• To avoid this we have to limit our apis accessing for particular user which is called throttling and it is easy to implement as well. Just have a look of implementing throttling in rest framework.

• This is the screenshot from rest framework documentation and this simple it is. You just need to change 100/day to your specific case.

OK guys I hope this blog helps you in some way and comment out even though If I follow all the above steps, with what way you will attack my production server☹️? I will include some other topics related to security like (CSRF, XSS, clickjacking, CORS, SQL injection) in my upcoming blogs.

If you have any questions feel free to reach me out among any of the below options. We can have 1:1 conversation as well if the issue needs to be discussed in detail. If there are any suggestions, reviews, questions please drop them in comment box. I would love to look at them.

💬 Let’s Connect! If you found this blog helpful, feel free to follow me for more insights and updates! You can connect with me on:

• Instagram: Click here
• LinkedIn: www.linkedin.com/in/ram-meegada
• Gmail: ramumeegada1811@gmail.com