Introduction
When planning an installation of Gravity Forms, there are many aspects of security that need to be considered carefully. The advice and best practices in this section is to help site owners and administrators to understand the issues and learn how to adjust the security features according to their needs.
This information complements the Gravity Forms Security Whitepaper.
Web Server and WordPress Security
Gravity Forms is only as secure as the server it’s installed on so it makes sense to begin your security assessment and configuration by reviewing the configuration of the system, the Web server and WordPress.
Web Server and WordPress Configuration
If you are running your own Web server, make sure your server is running the latest version of PHP and the web server and consider forcing HTTPS/SSL on all pages. Configure regular backups and keep all your plugins up-to-date at all times. Follow the advice in the WordPress documentation on hardening WordPress. It contains some excellent suggestions on how to secure the web server and how to handle risk mitigation in the event of a compromise.
You may also want to consider managed hosting, which can handle much of this for you. For example:
Security Plugins and Services
There are a number of plugins and services that can help improve the security of your site. For example, some popular plugins are:
- iThemes Security
- Wordfence
- All In One WP Security & Firewall
- BulletProof Security
However, these plugins do require some level of understanding so you may need to get someone qualified to help you set one up.
The following security services provide a firewall, a first line of defense, between attackers and your server. They’re an excellent way to prevent attacks before they even hit your server:
Updates
We do recommend that customers keep WordPress and all of their plugins and themes updated at all times as part of a regular maintenance plan. Not doing so is a serious security risk for your site. We also recommend that customers remove Gravity Forms from their sites if they no longer wish to keep their license active.
Gravity Forms Security Features
Once you’ve locked down the security on your server and on WordPress, you’ll want to have a look at the security features that Gravity Forms offers and adjust them according to your needs.
Automatic and Background Updates
Administrators see a notification on the WordPress dashboard to upgrade when a new release is available. If administrators have automatic background updates enabled, Gravity Forms will be updated automatically without the site owner needing to do anything on their end, and the update will install automatically. This is enabled by default on all new installations from version 1.9.2 onward.
Site owners can opt to remove automatic background updates through a simple change in the Gravity Forms settings or WordPress configuration file, but keeping the functionality is strongly recommended.
Automatic background updates will only occur for important bug fixes and security releases, not for major version releases.
Fine-Grained User Permissions
When providing access to users, it’s not necessary to give them permissions to perform all the functions in Gravity Forms. You can control exactly who can do what by assigning capabilities to user roles.
As a rule, it’s good practice to assign only the capabilities needed for the role and no more. See Role and Capability Management for the details.
Roles and capabilities are a security feature of WordPress, and you can read more about them in the WordPress documentation.
Although capabilities are an important part of WordPress security, there’s no way to manage them without a plugin. Fortunately, there are a number of plugins that can do this. One that we do recommend is the Members plugin.
Require Login
Gravity Forms can be configured to be displayed only to logged-in users. If this form setting is enabled, then a message will be displayed to anonymous users. These forms are protected by special security tokens called nonces that are refreshed every 12 hours so it’s important that these pages which require login are not cached otherwise the submissions will fail. The default settings for most caching plugins will allow this so it should not be an issue.
Anti-Spam Protection
Spam is a special sort of security issue. Mostly it’s just annoying, but it can become a serious issue if it goes unchecked. Gravity Forms supports multiple ways to detect spam. See the Spam Detection and Protection article for the details.
State Validation
Out of the box, Gravity Forms includes built-in form validation to help prevent spam and automated attacks. This protection is especially critical for forms that use pricing fields or integrate with payment gateways, since the validation automatically rejects submissions that attempt to send random or unexpected values to supported form fields. See the State Validation article for more details.
File Upload
For a full overview of file upload security in Gravity Forms, including upload restrictions, file storage, download access control, and off-server storage alternatives, see the File Upload Security article.
Sanitization of Data Submitted
Field values are sanitized by WordPress core functions during form submission and escaped on output.
Sensitive Data
Dynamic Population
Pages containing forms should be excluded from caching to prevent populated forms being cached and displayed to others.
If you have a form that will be populated with personal data (names, email addresses etc.) consider enabling the “Require user to be logged in” setting.
Entries
The entry data is not encrypted. This means you should not use Gravity Forms to store very sensitive data like credit card details or passwords that could result in serious issues in the event of a data breach.
The JSON REST API
Gravity Forms provides an API which can be activated by administrators on the settings page.
The API provides two methods of authentication
- For WordPress plugins and themes running in the same installation: WordPress cookie authentication.
- For external clients: signature authentication.
Cookie authentication is the basic authentication method included with WordPress. When users log in, this sets up the cookies, so plugin and theme developers need only to have a logged-in user.
The Gravity Forms Web API uses nonces in addition to authentication to avoid CSRF (Cross-Site Request Forgery) issues. This prevents other sites from forcing you to perform actions without explicitly intending to do so.
All requests from external applications are authenticated by checking an expiring signature. This is similar to the approach used by Amazon to secure access to their S3 Storage API. Once authenticated, standard WordPress capability-based authorization is used to ensure that the API request is allowed to be fulfilled.
If you’ve activated the Web API, make sure the private key is secure and strong. Create a dedicated user account for the API and assign it with the lowest privileges possible.
For further information on how to implement authentication in an API client, please consult the documentation for the Web API.
Content Security Policy
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to the distribution of malware.
To enable CSP, all script tags must contain a nonce attribute to be allowed to execute. As of Gravity Forms 2.5.8, script tags for the form inline scripts are now generated by WordPress 5.7+, which makes it possible to use the wp_inline_script_attributes filter to add attributes to the tag, such as the nonce required by CSP. Refer to this WordPress core team post for more details.
Verifying the integrity of the source code files
If you’re concerned that your files may have been tampered with, you can check by comparing the md5 checksums for each of the files. Checksums can be checked using the Gravity Forms CLI add-on. If you need the checksum file for a previous version, please get in touch with support and we’ll send it to you.
To verify the checksum, be sure you have the CLI add-on (and WP CLI, of course) installed and run the following command:
wp gf tool verify-checksums
Reporting Security Vulnerabilities
Security vulnerabilities in all software are inevitable, and we do our best to ensure that patches are developed, tested, released and announced as quickly as possible after they’ve been discovered. Full details are made available to customers and other trusted parties on request.
Occasionally, security researchers have contacted us to disclose a security vulnerability. In these cases, it’s understandable that the researcher might want to publish details of the discovery themselves. We do expect researchers to respect the principles of responsible disclosure and to work with us to coordinate the content and timing of the public disclosure, so customers are given a reasonable opportunity to update their sites.
If you have discovered a vulnerability in one of our products, we want to hear from you as soon as possible. Please gather as much information together as you can so we can work quickly to address it. Here’s a checklist of the details we’d like to see.
- Severity (high, medium, low)
- Vulnerability Type: e.g., DoS, Overflow, XSS, CSRF, etc
- Exploitation Requires Authentication?: yes/no
- Version(s) of Gravity Forms (or Add-On) affected
- A description of the vulnerability
- Do you have reason to believe the vulnerability is being exploited?
- Are details of an exploit publicly available? If so, please provide us with a URL.
- What is the potential impact? How do you envisage it being used in an attack scenario?
- DREAD score, if known.
- CVE Identifier / Reference / Advisory Number, if applicable.
- If you wish to be credited for the responsible disclosure in the release announcement and the change log, please let us know. If you plan to disclose details of the vulnerability, please do let us know so we can coordinate the timing of the disclosure together.
- Any additional comments.
If you are a customer, please open a support ticket as soon as possible and make it clear in the subject that you are reporting a security vulnerability.
If you are not a customer, send all the details to [email protected]. We have developers in a few time zones, so don’t assume you have to leave it until the morning.
We’ll acknowledge receipt as soon as we’ve read it. If confirmed, we’ll plan a patch and let you know when we plan to release it.