
Django Security
Harden a Django app before production by applying auth, CSRF, injection/XSS controls, and deployment-ready settings with your coding agent.
Overview
django-security is an agent skill most often used in Ship (also Build, Operate) that encodes Django authentication, authorization, and production security settings to reduce CSRF, injection, and XSS risk.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill django-securityWhat is this skill?
- Production settings template with DEBUG=False, ALLOWED_HOSTS, and env-based SECRET_KEY enforcement
- HTTPS and cookie hardening: SECURE_SSL_REDIRECT, secure/session flags, HSTS preload, X_FRAME_OPTIONS DENY
- Guidance for authentication, authorization, roles, CSRF, SQL injection, and XSS prevention
- Activation paths for greenfield auth setup, permission design, pre-launch review, and deploy
- Origin from Everything Claude Code (ECC) as a reusable Django security reference skill
Adoption & trust: 5.8k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are shipping a Django app but are unsure which production settings, cookie flags, and auth patterns actually block CSRF, injection, and XSS in the wild.
Who is it for?
Indie builders on Django who want a copy-paste production security baseline and a structured review pass before go-live.
Skip if: Teams that already run a formal AppSec program with automated DAST/SAST only—this skill supplements judgment, it does not replace penetration testing or compliance attestations.
When should I use this skill?
Setting up Django authentication and authorization; implementing permissions and roles; configuring production security; reviewing the app for vulnerabilities; deploying Django to production.
What do I get? / Deliverables
Your agent outputs hardened settings snippets and review guidance aligned to Django best practices so you can deploy with DEBUG off, TLS-backed cookies, and safer auth boundaries.
- Hardened production settings recommendations
- Security review notes on auth, CSRF, injection, and XSS areas
- Deployment configuration checklist
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Security hardening and production configuration sit in Ship where solo builders finalize apps before users touch them. The skill is a vulnerability-focused playbook (DEBUG off, cookies, HSTS, auth patterns)—canonical on the security subphase shelf.
Where it fits
Wire user roles and permission checks while the agent cites Django auth patterns from the skill.
Run a pre-launch pass on settings.py for DEBUG, cookies, and HSTS before tagging a release.
Generate production.py env-var requirements for ALLOWED_HOSTS and SECRET_KEY on your host.
Re-open the skill after a domain or CDN change to verify cookie SameSite and SSL redirect still match policy.
How it compares
Use as a Django-focused security checklist skill instead of generic OWASP chat advice that ignores framework-specific middleware and settings.
Common Questions / FAQ
Who is django-security for?
Solo and indie developers building Django SaaS or APIs who need framework-native guidance on auth, CSRF, cookies, and production settings without hiring a security consultant for every release.
When should I use django-security?
During Build when wiring auth and permissions, in Ship when flipping DEBUG off and configuring HTTPS/HSTS, before deploy when validating ALLOWED_HOSTS and secrets, and in Operate when re-auditing settings after infra changes.
Is django-security safe to install?
It is documentation-style procedural knowledge without built-in shell or network side effects; review the Security Audits panel on this Prism page and inspect the skill package in your repo before trusting third-party ECC-origin content.
SKILL.md
READMESKILL.md - Django Security
# Django Security Best Practices Comprehensive security guidelines for Django applications to protect against common vulnerabilities. ## When to Activate - Setting up Django authentication and authorization - Implementing user permissions and roles - Configuring production security settings - Reviewing Django application for security issues - Deploying Django applications to production ## Core Security Settings ### Production Settings Configuration ```python # settings/production.py import os DEBUG = False # CRITICAL: Never use True in production ALLOWED_HOSTS = os.environ.get('ALLOWED_HOSTS', '').split(',') # Security headers SECURE_SSL_REDIRECT = True SESSION_COOKIE_SECURE = True CSRF_COOKIE_SECURE = True SECURE_HSTS_SECONDS = 31536000 # 1 year SECURE_HSTS_INCLUDE_SUBDOMAINS = True SECURE_HSTS_PRELOAD = True SECURE_CONTENT_TYPE_NOSNIFF = True SECURE_BROWSER_XSS_FILTER = True X_FRAME_OPTIONS = 'DENY' # HTTPS and Cookies SESSION_COOKIE_HTTPONLY = True CSRF_COOKIE_HTTPONLY = True SESSION_COOKIE_SAMESITE = 'Lax' CSRF_COOKIE_SAMESITE = 'Lax' # Secret key (must be set via environment variable) SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY') if not SECRET_KEY: raise ImproperlyConfigured('DJANGO_SECRET_KEY environment variable is required') # Password validation AUTH_PASSWORD_VALIDATORS = [ { 'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator', }, { 'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator', 'OPTIONS': { 'min_length': 12, } }, { 'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator', }, { 'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator', }, ] ``` ## Authentication ### Custom User Model ```python # apps/users/models.py from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): """Custom user model for better security.""" email = models.EmailField(unique=True) phone = models.CharField(max_length=20, blank=True) USERNAME_FIELD = 'email' # Use email as username REQUIRED_FIELDS = ['username'] class Meta: db_table = 'users' verbose_name = 'User' verbose_name_plural = 'Users' def __str__(self): return self.email # settings/base.py AUTH_USER_MODEL = 'users.User' ``` ### Password Hashing ```python # Django uses PBKDF2 by default. For stronger security: PASSWORD_HASHERS = [ 'django.contrib.auth.hashers.Argon2PasswordHasher', 'django.contrib.auth.hashers.PBKDF2PasswordHasher', 'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher', 'django.contrib.auth.hashers.BCryptSHA256PasswordHasher', ] ``` ### Session Management ```python # Session configuration SESSION_ENGINE = 'django.contrib.sessions.backends.cache' # Or 'db' SESSION_CACHE_ALIAS = 'default' SESSION_COOKIE_AGE = 3600 * 24 * 7 # 1 week SESSION_SAVE_EVERY_REQUEST = False SESSION_EXPIRE_AT_BROWSER_CLOSE = False # Better UX, but less secure ``` ## Authorization ### Permissions ```python # models.py from django.db import models from django.contrib.auth.models import Permission class Post(models.Model): title = models.CharField(max_length=200) content = models.TextField() author = models.ForeignKey(User, on_delete=models.CASCADE) class Meta: permissions = [ ('can_publish', 'Can publish posts'), ('can_edit_others', 'Can edit posts of others'), ] def user_can_edit(self, user): """Check if user can edit this post.""" return self.author == user or user.has_perm('app.can_edit_others') # views.py from django.contrib.auth.mixins import LoginRequiredMixin