Security Best Practices

• Introduction
• Web Server and WordPress Security
• Web Server and WordPress Configuration
• Security Plugins and Services
• Updates
• Gravity Forms Security Features
• Automatic and Background Updates
• Fine-Grained User Permissions
• Require Login
• Anti-Spam Protection
• File Upload Security
• Limit file uploads to logged in users
• File Upload Field Settings - Allowed File Extensions
• The Gravity Forms Uploads Folder
• Field Upload Field Merge Tags
• Changing the Gravity Forms Upload Path
• The .htaccess File
• The File Upload Field Button
• Secure Download Locations
• Forced Downloads
• Sanitization of Data Submitted
• Sensitive Data
• Dynamic Population
• Entries
• The JSON REST API
• Content Security Policy
• Verifying the integrity of the source code files
• Reporting Security Vulnerabilities

Introduction

When planning an installation of Gravity Forms there are many aspects of security that need to be considered very 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:

• WP Engine
• Pagely
• Kinsta

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:

• Sucuri
• CloudFlare
• Incapsula

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 in WordPress you’ll want to take 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 giving 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.

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 get 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 provides three ways to help combat spam:

• The honeypot form setting activates a common technique to trick bots into revealing themselves. It’s generally a good idea to activate this setting for all forms. In Gravity Forms v2.7, we enhanced the way the honeypot works. You can read about the enhancements here.
• Akismet integration with our Akismet Add-On.
• CAPTCHA. This will display a field that requires the user to prove they’re human before they’re allowed to submit the form. We offer the following CAPTCHA integrations:
  • Built-in CAPTCHA field
    • Third-Party add-ons can extend our CAPTCHA field to include different types of CAPTCHA
  • reCAPTCHA Add-On
  • Cloudflare Turnstile Add-On

File Upload Security

We’re sometimes asked about the security around the file upload feature. Files can only be uploaded to the server if there’s a file upload field on an active form. If no active forms have a file upload field then no files can be uploaded to the server.

Limit file uploads to logged in users

If possible, set your form to require login. This will ensure that file uploads are only performed by authenticated users. If requiring login is not an option for you then please read the rest of this section carefully.

File Upload Field Settings – Allowed File Extensions

When a file upload field is added to a form make sure you configure the “allowed extensions” setting to be as restrictive as possible. There are certain extensions that Gravity Forms will always block to protect from attacks but it’s good practice to limit the extensions to the file extensions you expect to receive.

The Gravity Forms Uploads Folder

Gravity Forms creates a subfolder structure in the WordPress uploads root which is used to save uploaded files. Files are stored in folders with unique names created with the same algorithm WordPress uses (salted HMAC-MD5) and are impossible to crack with brute force. A folder containing the files for the form will have a path similar to this:
/path/to/wordpress/wp-content/uploads/gravity_forms/82-ea1cf844318d032fd7e8fa8w1dacdfbe

You will notice empty index.html files in all of the subfolders. The purpose of these files is to prevent directory listings appearing in search engines for Web servers that are poorly configured. Please don’t remove these files, they are there to protect you.

Field Upload Field Merge Tags

Files are safe as long as the folder name is not shared for that form. This means merge tags can be used for notifications to administrators however, if files are confidential, it’s not safe to use file upload merge tags in confirmations or notifications to non-administrative users.

Changing the Gravity Forms Upload Path

You may wish to increase the security of your uploaded files by changing the place they’re stored to a different place on the server. You can do this by using the gform_upload_path filter. If you do this, you’ll need to ensure that the Web server has the appropriate permissions to read and write to that folder. You could also put the files in a different server entirely using the gform_after_submission filter.

The .htaccess File

In the root of the Gravity Forms uploads folder, an .htaccess file will be generated which, for most servers, disables PHP from being parsed within the subfolder structure. This .htaccess file is written with the most common server configurations in mind but you may need to tweak it or even remove it completely by using the gform_upload_root_htaccess_rules filter. This filter returns each of the lines of the file in an array. For example, to prevent the .htaccess file from being written use the following line:

add_filter( 'gform_upload_root_htaccess_rules', '__return_false' );

Please bear in mind though that this file is there to protect your server, so the filter should only be used if you’re seeing an error. Please consult your server administrator or get in touch with support before using this filter.

The File Upload Field Button

Gravity Forms allows users with permissions to edit forms to add File Upload fields to forms. If you’d like to remove this field from the toolbox this can be easily achieved by adding a snippet of code. Check out the documentation on the gform_add_field_buttons filter for further details and sample code.

Secure Download Locations

By default, file download URLs will be obscured. This ensures that an individual cannot determine where the file is stored on the server.

If you need to turn secure file downloads off (not recommended), the gform_secure_file_download_location filter can be used.

The gform_require_login_pre_download filter can be used to require the user be logged in before the download URL will allow access to the file.

The gform_permission_granted_pre_download filter can be used to perform custom logic, such as user capability checks, to determine if the download URL will allow access to the file.

Check out the Troubleshooting Issues with Download Links if you run into issues with any of the above filters.

Forced Downloads

Gravity Forms downloads can be forced, preventing it from being opened inside the browser. For more information, see the File Upload field merge tag modifiers.

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

1. For WordPress plugins and themes running in the same installation: WordPress cookie authentication.
2. 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 WPCLI, 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.

On occasion, 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.

1. Severity (high, medium, low)
2. Vulnerability Type: e.g., DoS, Overflow, XSS, CSRF, etc
3. Exploitation Requires Authentication?: yes/no
4. Version(s) of Gravity Forms (or Add-On) affected
5. A description of the vulnerability
6. Do you have reason to believe the vulnerability is being exploited?
7. Are details of an exploit publicly available? If so, please provide us with a URL.
8. What is the potential impact? How do you envisage it being used in an attack scenario?
9. DREAD score, if known.
10. CVE Identifier / Reference / Advisory Number, if applicable.
11. 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.
12. 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 your 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 till 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.