Django开发者坦白：生产环境中必须避免的坑！🚨

嘿，你有没有在生产环境中犯过下面这些错误？让我们来看看每个Django开发者都必须避免的几个常见错误。在我以前的经历中，我几乎都犯过这些错误😥。

1. 调试 = True

为什么我们不应该在生产环境中使用“Debug = True”呢？🤔 请看下面的图。

Image-1 (调试模式=True)

图片 — 2，调试关闭

我故意在代码中犯错来解释其中的区别。在第一张图片中，当“Debug=True”时，Django 会追踪每个错误，并显示所有相关细节。向下滚动后，你会发现很多敏感信息，比如配置设置、文件存储路径、源代码和依赖项等。

实际上，这种错误跟踪仅用于开发目的，使开发人员更容易调试。但在实际使用中，这并不是个好主意。

*2. ALLOWED_HOSTS = [""]**

在生产环境中使用它会导致几种常见的安全威胁，例如主机头部攻击（Host Header攻击）。

• 攻击者会从恶意的主机头向服务器发送请求，以改变服务器的响应行为。
• 你的服务器会接受任何域名或IP，但在生产环境中这并不期望，因为它只处理来自特定域名的流量。假设你的服务器可以处理一定量的流量。现在，攻击者或者你的竞争对手😜会从不同的伪造域名发送不必要的并发请求，会使你的服务器宕机。攻击者厉害，开发者震惊😂。
• 如果开发人员为了性能使用了缓存，并且还设置了ALLOWED_HOSTS = ["*"] 来安全地允许攻击😎，那么也存在缓存操纵的风险。让我解释一下这意味着什么。比如说，如果开发人员缓存了包含使用域名链接（例如“http://<request.get_host() >/all-posts/”）的响应，那么当真实用户访问该缓存并点击链接时，将会被重定向到恶意网站上。

我们使用 request.get_host() 在 Django 中获取主机名或域名。

3. 在生产中使用runserver

• python manage.py runserver 命令仅用于开发环境，因为 runserver 是单线程的。
• 它 无法处理并发请求，不适合生产环境中的高流量。
• 在生产环境中，应使用如“gunicorn”这样的 web 服务器。如果处理 双向通信（如 Websockets），建议使用 Uvicorn、daphne 等，因为这些是 ASGI（异步服务器网关接口）服务器。

请注意：“gunicorn” 不能处理 websocket，因为它是一个 WSGI (Web 服务器网关接口) 服务器，所以无法处理 websocket。

4. 把所有内容硬编码

• 不要在任何应用文件里硬编码配置，最好把配置放在.env文件中，并且别忘了添加.gitignore。

5. 不进行 API 的验证。

• 在开发阶段，大多数开发者懒得对API进行认证，因为在测试时直接调用API比每次token过期时都去更改token要方便得多。然而，攻击者会精神抖擞💪😃，如果发现没有认证的话。
• 潜在的问题有数据泄露、数据泄露和数据处理不当。

6. API 请求限制

• 如果我的应用与你的应用存在竞争，我想让你的服务器下线怎么办？即使你遵循了上述所有做法，我还是有一个办法。
• “我将成为你应用的授权用户，并不断循环调用多个API，直到你的服务器崩掉😈。我就是那个危险的人😂”。
• 要避免这种情况，我们需要限制特定用户对API的访问，这叫作限速，而且实现起来也很简单。可以看看如何在REST框架中实现限速。

• 这是来自rest框架文档的内容，特别简单。你只需要将“每天100”改为适合你的情况。

好的大家，希望这篇博客能在某些方面帮助到你们，尽管留下评论。即使我按照上述步骤操作，你会用什么方式攻击我的生产服务器？☹️
在我的下一个博客中，我还会涉及一些其他与安全相关的话题，比如CSRF、XSS、点击劫持攻击、CORS、SQL注入等。

如果有任何问题，你可以随时通过下面的任何一种方式联系我。如果需要详细讨论，我们可以一对一聊。有任何建议、意见或问题都可以直接在评论区留言。我非常乐意看看你的留言。

💬 让我们相互连接！ 如果你觉得这个博客有帮助，欢迎关注我以了解更多见解和最新消息！你可以通过微博或者我的网站联系我。

• Instagram: 点这里
• LinkedIn: www.linkedin.com/in/ram-meegada
• Gmail: Gmail邮箱 ramumeegada1811@gmail.com