Will It Vibe?Model field looks like it stores a plaintext password
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A model field named password/passwd/pwd is declared as a plain CharField/TextField. Django's own User model (and AbstractBaseUser) never store a password this way; they store a salted hash and expose set_password()/check_password(). A field named exactly 'password' on a CharField is strong evidence of a hand-rolled, unhashed credential store.
Why it matters
A model field named password (or passwd/pwd) declared as a plain CharField/TextField stores exactly what is written to it: if the application ever assigns a raw password string to that field, it is stored in plaintext in the database. Anyone with read access to the database, a backup, or a SQL injection elsewhere in the app gets every user's real password, not a hash they would still have to crack.
How to fix it
If this field is meant to hold a user's login credential, remove it and use Django's built-in User model (or a custom model extending AbstractBaseUser), which stores a salted hash and exposes set_password()/check_password()/is_password_usable(). If it must stay a custom model for a non-Django-auth reason, hash it explicitly with django.contrib.auth.hashers.make_password() before saving and rename the field to make clear it holds a hash (password_hash), never the raw value.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo