This page contains some frequently asked questions related to security. Please review this before raising security issue with Frappe team.

Frappe allows uploading malicious files like .EXE

Frappe is not an anti-virus, so it doesn't scan any kind of files that get uploaded. Frappe has inbuilt validation to block certain extensions and you can tweak this from "System Setting" > Files > Allowed File Extensions.

Frappe shows complete traceback of error

Error traces help developers debug issues faster. In vast majority of the cases they do not reveal anything that isn't already available in our source code which is open source. If you still wish to disable tracebacks then go to "System Settings" and uncheck "Show Full Error and Allow Reporting of Issues to the Developer"

Frappe doesn't encrypt the password when sending a request

Frappe recommends proper HTTPS (TLS) setup in production, if that is setup properly every request is encrypted at transport layer, so there is little security benefit from encrypted request content manually again on top of it.

If you're using a tool like Burp Suite to intercept an encrypted request by setting up a proxy/certificate that allows you to see unencrypted traffic then you're not really operating in real threat model. In real world, if TLS is compromised, you have much bigger problems.

In addition to this Frappe stores login password with PBKDF2 + SHA256 hash. Once stored, it's not possible to retrieve the passwords. Password fields that need value to be retrievable (e.g. API secrets) are stored with symmetric encryption using Fernet.

Frappe enables "autocomplete" on password fields

Autocomplete + password managers are widely considered as better option for security and UX. Disabling autocomplete is outdated practice and major browsers don't even respect it if you disable it. Refer:

Frappe doesn't expire passwords every 30/90 days

Password rotation isn't necessarily secure and can even cause harmful side effects:

If you still want this behaviour you can enable it from "System Settings" > "Force User to Reset Password"

Frappe doesn't allow configuring password requirements to include upper, lowercase and special characters

Hard-coded requirements for passwords are generally bad UX. Password strength is largely based on entropy, see this comic for a good illustration of this:

Frappe instead runs heuristics to compute password strength. By default we require a reasonably strong password, but if you want to increase this strength then you can configure it in "System Settings" > "Password" > " Minimum Password Score"

Frappe sets cookie path to / which can allow other applications on same origin to use the cookie

Frappe doesn't allow configuring different applications on different paths. So this can't happen. By default, all pages on your configured domain/subdomain are served by Frappe.

Frappe doesn't add "Secure" flag to cookies

Frappe adds a "Secure" flag to cookies only when it's accessed from the HTTPS scheme.

We recommend enabling HSTS on your domain so unencrypted traffic is blocked.

We allow non-HTTPS connections to support deployments in internal networks where users might not want to setup TLS.

The site reveals that it's running on Frappe

It is trivial to figure out which application a site is running if you know application characteristics. E.g. preload headers, asset file names, and API paths. It's impossible to mask all of this information.

Even if we hide branding from UI, it won't take much time to figure out that a particular site is running on Frappe.

On this page