Gravity Forms 文档

Sending Product Information to Google Sheets using Zapier (v3 and earlier)

DescriptionBackgroundRequirements for this ExampleStep-By-Step

Superceded: This technique applies to Gravity Forms Zapier Add-On version 3 and earlier.

Description

This step-by-step example shows you how to send a list of product information, as collected from a form, to a Google spreadsheet, using the Zapier Add-On.

Background

As of version 3 of the Zapier Add-On, product information is sent to Zapier as an array, use of which is what this example demonstrates. This change allows you to use the option in Zapier that creates new rows with line item support.

In addition, the list data is also still being sent as a serialized string, simply to maintain backwards compatibility.

Requirements for this Example

A form that has product fieldsGravity Forms Zapier Add-On v3 or higher, available from the Downloads page for appropriately licensed usersA Zapier accountAccess to Google Docs

Step-By-Step

Below are the steps to follow so that product data will be sent to a Google spreadsheet as separate line items.

While viewing the Form, mouse-over the Settings link towards the top and select Zapier.

Click the Add New button to add a new feed.Name your 「Zap」.Open a new browser window and log into your Zapier account.Click the Make a Zap! button towards the top.The option to Choose a Trigger App appears. Select Gravity Forms as the application.Choose New Form Submission as the trigger and click the Save + Continue button.At this point, you are presented with a URL for the new Zap. Copy this URL and return to the window for your Form』s Feed Setup.Paste the URL into the Webhook URL field.Click the Save Zapier Feed button.

Return to the browser window for setting up the Zap in Zapier.Click the Ok, I did this button.The next screen displays sample data of how a submission from your Form would appear. Click the Continue button.The option to Choose an Action App displays. Select Google Sheets as the application.Select the option Create one or more new rows in a specific spreadsheet (with line item support). If you do not see that option, you may have to reveal it by expanding your choices with the 「show less common actions」 link. Click the Save + Continue button.Connect to the Google Account where your spreadsheet exists and click Save + Continue. If you have not already created a spreadsheet for the product information, do so now because it is needed in the next step.Select the spreadsheet and the worksheet.The row headers in the spreadsheet now display. The Product Data to use for list items displays in the field list with Products/ pre-pending the data. Because Zapier 3.0 is backwards compatible, you will still see individual fields for the product information. These do not work as line items and can be ignored. Map the product fields to your row header. If you notice data you didn』t include in your spreadsheet, you can simply add a new header to your spreadsheet and click the Refresh Fields button and the new row will be pulled in for you to map. Click the Continue button once your mapping is complete.At this point, a test row may be sent to your spreadsheet for your review. You may skip this step if you wish.Click Finish.Name your zap and turn it ON.Your Zap is now ready to process form submissions to populate your spreadsheet.

Send Notifications on Payment Events

By default Gravity Forms only sends notifications for the form submission event, however, it is possible to define you own custom events.

Note: The ability to assign notifications to be sent on payment events is now a built-in feature of Gravity Forms Authorize.net Add-On 2.1.4+, Gravity Forms PayPal Standard Add-On 2.6+, and Gravity Forms Stripe Add-On 2.0+ when running Gravity Forms 1.9.12+. For those running these versions the following code snippets are no longer required.
The first step is to list the event in the event drop down on the edit notification page. You can do this using the gform_notification_events filter.
12345678910111213141516171819202122232425add_filter( 'gform_notification_events', function ( $notification_events, $form ) {    $has_stripe_feed            = function_exists( 'gf_stripe' ) ? gf_stripe()->get_feeds( $form['id'] ) : false;    $has_paypal_feed            = function_exists( 'gf_paypal' ) ? gf_paypal()->get_feeds( $form['id'] ) : false;    $has_paypalpaymentspro_feed = function_exists( 'gf_paypalpaymentspro' ) ? gf_paypalpaymentspro()->get_feeds( $form['id'] ) : false;    $has_authorizenet_feed      = function_exists( 'gf_authorizenet' ) ? gf_authorizenet()->get_feeds( $form['id'] ) : false;     if ( $has_stripe_feed || $has_paypal_feed || $has_paypalpaymentspro_feed || $has_authorizenet_feed ) {        $payment_events = array(            'complete_payment'          => __( 'Payment Completed', 'gravityforms' ),            'refund_payment'            => __( 'Payment Refunded', 'gravityforms' ),            'fail_payment'              => __( 'Payment Failed', 'gravityforms' ),            'add_pending_payment'       => __( 'Payment Pending', 'gravityforms' ),            'void_authorization'        => __( 'Authorization Voided', 'gravityforms' ),            'create_subscription'       => __( 'Subscription Created', 'gravityforms' ),            'cancel_subscription'       => __( 'Subscription Canceled', 'gravityforms' ),            'expire_subscription'       => __( 'Subscription Expired', 'gravityforms' ),            'add_subscription_payment'  => __( 'Subscription Payment Added', 'gravityforms' ),            'fail_subscription_payment' => __( 'Subscription Payment Failed', 'gravityforms' ),        );         return array_merge( $notification_events, $payment_events );    }     return $notification_events;}, 10, 2 );

Once you have added the events to the drop down you can then go and edit your notifications (or create new notifications) and assign them to your new events.
The events drop down only appears on the edit notification page when multiple notification events exist for the form, it will appear between the notification name and send to settings.
Assigning a notification to a custom event will prevent it being sent during submission. You will need to manually trigger the sending of the event notifications at the appropriate time. For payment related events we can use the gform_post_payment_action action hook and the GFAPI::send_notifications method.
1234add_action( 'gform_post_payment_action', function ( $entry, $action ) {    $form = GFAPI::get_form( $entry['form_id'] );    GFAPI::send_notifications( $form, $entry, rgar( $action, 'type' ) );}, 10, 2 );
The above code snippets should be placed in the functions.php file of your active theme.

Note: These snippets will only work if the form has a payment feed using the Stripe, PayPal Standard (min v2.0) or Authorize.net (v2.0) add-ons. Support has been added for PayPal Payments Pro (v2.0) add-on which is currently in development. The legacy PayPal Pro add-on and earlier versions of the previously mentioned add-ons are not supported.

Sending List Field and Product Data as Arrays to Zapier

DescriptionList FieldSample List Field FormSample Data for List Field FormSample for List Field Form Submission Data in ZapierSample for Mapping List Field Form Data in ZapierProduct FieldSample Product FormSample Data for Product FormSample for Product Form Submission Data in ZapierSample for Mapping Product Form Data in Zapier

Description
A very important change was implemented with Zapier 3.0. The data for List and Product fields is now sent to Zapier as an array. To maintain backwards compatibility, the data continues to be sent as a serialized string for the List field and individual fields for the Product fields as well. This new change should make consuming List and Product Field data much easier by the applications available in Zapier.
List Field
When the List field data is sent to Zapier, the data will be pre-pended with the name of the List field and a 」 /」. Below is a sample form using the List field with what the data would look like when sent to Zapier. This List field was set up to have three columns.
Sample List Field Form

Sample Data for List Field Form
This is what the data looks like when sent to Zapier.
123456789101112131415161718192021222324[Event Attendees /] => Array        (            [0] => Array                (                    [Attendee] => Malcolm Reynolds                    [Guest 1] => Zoe Washburne                    [Guest 2] => Jayne Cobb                )             [1] => Array                (                    [Attendee] => Inara Serra                    [Guest 1] => Kaylee Frye                    [Guest 2] => Shepherd Book                )             [2] => Array                (                    [Attendee] => Simon Tam                    [Guest 1] => River Tam                    [Guest 2] => Hoban Washburne                )         )
Sample for List Field Form Submission Data in Zapier
This is how the form submission data from above looks in Zapier. You will notice the List field is still available in the data as a serialized string for backwards compatibility.

Sample for Mapping List Field Form Data in Zapier
This is how the data appears in Zapier when mapping it for an application. You will notice the List field is still available in the data as a serialized string for backwards compatibility.

Product Field
When the Product-related field data is sent to Zapier, the data will be pre-pended with the text 「Products /「. Below is a sample form with two Single Product fields with an Option field each, a Shipping field, and a Total field with what the data would look like when sent to Zapier. The Shipping field will be sent as the last 「product」 in the Products array. In the data example below, each product with its id, name, quantity, price, options, price with options, and subtotal is a separate array within the Products array.
Sample Product Form

Sample Data for Product Form
This is what the product form data looks like when sent to Zapier.
123456789101112131415161718192021222324252627282930313233343536[Products /] => Array        (            [0] => Array                (                    [product_id] => 1                    [product_name] => Frankenstein's Monster T-Shirt                    [product_quantity] => 1                    [product_price] => 15                    [product_price_with_options] => 15                    [product_subtotal] => 15                    [product_options] => Blue                )             [1] => Array                (                    [product_id] => 5                    [product_name] => Creature from the Black Lagoon T-Shirt                    [product_quantity] => 1                    [product_price] => 15                    [product_price_with_options] => 15                    [product_subtotal] => 15                    [product_options] => Grey                )             [2] => Array                (                    [product_id] => 3                    [product_name] => Shipping                    [product_quantity] => 1                    [product_price] => 7                    [product_price_with_options] => 7                    [product_subtotal] => 7                    [product_options] =>                 )         )
Sample for Product Form Submission Data in Zapier
This is how the form submission data for the product form looks in Zapier. You will notice the Product information is still available in the data as separate fields for backwards compatibility.

Sample for Mapping Product Form Data in Zapier
This is how the product data appears in Zapier when mapping it for an application.You will notice the Product information is still available in the data as separate fields for backwards compatibility.

Select Field

IntroductionExampleUses

Introduction
The select type field, part of the Settings API, allows the user to select a choice from a drop down.
Example
The following example shows a section with two select type fields. The first is a simple select with two choices. The second select field has two choices with the first choice having sub-choices (an option group).
array(
'title' => esc_html__( 'This is the title for Section 1', 'sometextdomain' ),
'description' => esc_html__( 'This is a description of the purpose of Section 1', 'sometextdomain' ),
'fields' => array(
array(
'type' => 'select',
'name' => 'myselect',
'label' => esc_html__( 'This is a select', 'sometextdomain' ),
'choices' => array(
array(
'label' => esc_html__( 'my first choice', 'sometextdomain' ),
'value' => '1'
),
array(
'label' => esc_html__( 'my second choice', 'sometextdomain' ),
'value' => '2'
)
)
),
array(
'type' => 'select',
'name' => 'myselect2',
'label' => esc_html__( 'This is my select', 'sometextdomain' ),
'default_value' => 'first - 3',
'choices' => array(
array(
'label' => esc_html__( 'This is my first choice', 'sometextdomain' ),
'value' => 'first',
'choices' => array(
array(
'label' => esc_html__( 'first - 1', 'sometextdomain' ),
'value' => 'f1'
),
array(
'label' => esc_html__( 'first - 2', 'sometextdomain' ),
'value' => 'f2',
),
array(
'label' => esc_html__( 'first - 3', 'sometextdomain' ),
),
),
),
array(
'label' => esc_html__( 'This is my second choice', 'sometextdomain' ),
'value' => 'second',
),
),
)
),
),

The code above will render the select fields similar to the following:

Uses

settings_select()
get_select_options()
get_select_option()

Select Custom Field

IntroductionExampleUses

Introduction
The select_custom type field, part of the Settings API, allows the user to select a choice in a drop down or enter their own custom value in a text input.
Example
This field will output a select field containing the specified choices. In this example get_field_map_choices() is used to return an array of choices containing the date type fields from the current form.
It will also have an extra choice appended to the end of the list which when selected will hide the select field and display a text field allowing the user to enter a custom choice.
The content from the after_input property will appear after the text input, it will be hidden when the select is displayed.
array(
'title' => esc_html__( 'This is the title for Section 1', 'sometextdomain' ),
'fields' => array(
array(
'name' => 'cardDueDate',
'type' => 'select_custom',
'label' => esc_html__( 'Due Date', 'sometextdomain' ),
'after_input' => ' ' . esc_html__( 'days after today', 'sometextdomain' ),
'choices' => $this->get_field_map_choices( rgget( 'id' ), 'date' ),
'required' => true,
),
),
),

The code above will render the select field similar to the following:

When the 「Add Custom Due Date」 choice is selected the select will be hidden and a text input like this would be displayed:

Uses

settings_select_custom()
settings_select()
settings_text()

Security Best Practices

IntroductionWeb Server and WordPress SecurityWeb Server and WordPress ConfigurationSecurity Plugins and ServicesUpdatesGravity Forms Security FeaturesAutomatic and Background UpdatesFine-Grained User PermissionsRequire LoginAnti-Spam ProtectionFile Upload SecurityLimit file uploads to logged in usersFile Upload Field Settings – Allowed File ExtensionsThe Gravity Forms Uploads FolderField Upload Field Merge TagsChanging the Gravity Forms Upload PathThe .htaccess FileThe File Upload Field ButtonSecure Download LocationsForced DownloadsSanitization of Data SubmittedSensitive DataDynamic PopulationEntriesThe JSON REST APIContent Security PolicyVerifying the integrity of the source code filesReporting 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 EnginePagelyKinsta

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 SecurityWordfenceAll In One WP Security & FirewallBulletProof 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:

SucuriCloudFlareIncapsula

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 have this setting activated for all forms.Akismet plugin integration.CAPTCHA field. This will display a field which requires the user to prove they』re human before they』re allowed to submit the form.

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

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 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.

Severity (high, medium, low)Vulnerability Type: e.g., DoS, Overflow, XSS, CSRF, etcExploitation Requires Authentication?: yes/noVersion(s) of Gravity Forms (or Add-On) affectedA description of the vulnerabilityDo 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 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.

Gravity Forms Security Whitepaper

OverviewExecutive SummaryAn Overview of Gravity FormsThe Gravity Forms Leadership TeamThe Gravity Forms Release CycleVersion Numbering and Security ReleasesVersion Backwards CompatibilityGravity Forms and Security2013 OWASP Top 10A1 – InjectionA2 – Broken Authentication and Session ManagementA3 – Cross Site Scripting (XSS)A4 – Insecure Direct Object ReferenceA5 – Security MisconfigurationA6 – Sensitive Data ExposureA7 – Missing Function Level Access ControlA8 – Cross Site Request Forgery (CSRF)A9 – Using Components with Known VulnerabilitiesA10 – Unvalidated Redirects and ForwardsFurther Security Risks and ConcernsXXE (XML eXternal Entity) processing attacksSSRF (Server Side Request Forgery) AttacksAppendixCore WordPress APIsDatabase APIHTTP APIPermissions and current user API

Learn more about Gravity Forms software security in this free white paper which is forked from the original security white paper for WordPress.
Overview
This document is an analysis and explanation of the Gravity Forms software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating Gravity Forms as a form design and management system or web application framework should use this document in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.
The information in this document is up-to-date for the latest stable release of the software, Gravity Forms 1.9.4 at time of publication, but should be considered relevant also to the most recent versions of the software as backwards compatibility is a strong focus for the Gravity Forms development team. Specific security measures and changes will be noted as they have been added to the core software in specific releases. It is strongly encouraged to always be running the latest stable version of Gravity Forms to ensure the most secure experience possible.
Executive Summary
Gravity Forms is a dynamic open-source form management system which is used to power websites and web applications. It currently powers more than 1.5 million websites on the Internet. The usability and extensibility make it a popular and secure choice for websites of all sizes.
Since its inception in 2007, Gravity Forms has undergone continual hardening so its software can address and mitigate common security threats, including the Top 10 list identified by The Open Web Application Security Project (OWASP) as common security vulnerabilities, which are discussed in this document.
The Gravity Forms Development Team, in collaboration with the Gravity Forms Leadership Team, works to identify and resolve security issues in the software available for purchase at gravityforms.com, as well as recommending and documenting security best practices for third-party add-on and theme authors.
Site developers and administrators should pay particular attention to the correct use of the WordPress and Gravity Forms APIs and underlying server configuration which have been the source of common vulnerabilities, as well as ensuring all users employ strong passwords to access Gravity Forms.
An Overview of Gravity Forms
Gravity Forms is a commercial open source form management system (FMS). It is licensed under the General Public License (GPLv2 or later).
The Gravity Forms Leadership Team
Gravity Forms is developed by Rocketgenius Inc., run by a leadership team, and led by its co-founders Carl Hancock, Kevin Flahaut and Alex Cancado. The team governs all aspects of the project, including development, gravityforms.com, and community initiatives.
The Leadership Team has final authority on technical decisions, and lead architecture discussions and implementation efforts.
The Gravity Forms Release Cycle
Each Gravity Forms release cycle is led by one or more of the Gravity Forms developers. A release cycle usually lasts around 1 month from the initial scoping meeting to launch of the version.
A release cycle follows the following pattern:

Phase 1: Planning and securing team leads. This is done via chat using HipChat and Trello. The release lead discusses features for the next release of Gravity Forms. Gravity Forms developers get involved with that discussion. The release lead will identify tasks for each of the developers.
Phase 2: Development work begins. Regular chats are scheduled to ensure the development keeps moving forward.
Phase 3: Beta. Betas are released, and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are carried out from this phase on. Third-party add-on and theme authors are encouraged to test their code against the upcoming changes.
Phase 4: Launch. Gravity Forms version is launched and made available on the Gravity Forms downloads page. Soon after it is made available to installations for automatic and background updates.

Version Numbering and Security Releases
A major Gravity Forms version is dictated by the first two sequences. For example, 3.5 is a major release, as is 1.6, 1.7, or 2.0. There isn』t a 「Gravity Forms 3」 or 「Gravity Forms 4」 and each major release is referred to by its numbering, e.g., 「Gravity Forms 1.9.」
Major releases may add new user features and developer APIs. Though typically in the software world, a 「major」 version means you can break backwards compatibility, Gravity Forms strives to never break backwards compatibility. Backwards compatibility is one of the project』s most important philosophies, with the aim of making updates much easier on users and developers alike.
A minor Gravity Forms version is dictated by the third sequence. Version 1.9.3 is a minor release, as is 1.9.3.1. A minor release is reserved for fixing security vulnerabilities and addressing critical bugs only. Since new versions of Gravity Forms are released so frequently — the aim is every 1 month for a major release, and minor releases happen as needed — there is only a need for major and minor releases.
Version Backwards Compatibility
The Gravity Forms team has a strong commitment to backwards compatibility. This commitment means that whenever possible add-ons, themes, plugins, and custom code continues to function when Gravity Forms is updated, encouraging site owners to keep their Gravity Forms version updated to the latest secure release.
Gravity Forms and Security
The Gravity Forms Development Team often collaborates with security specialists to address issues in common dependencies, such as resolving the issues file upload field in versions up to 1.8.19
The Gravity Forms Leadership Team believes in Responsible Disclosure by alerting the development team immediately of any potential vulnerabilities. Potential security vulnerabilities can be signaled to the development team directly via the email address: [email protected]. The Development Team communicates amongst itself via a private email list, and HipChat and works on a walled-off, private repository for tracking, testing, and fixing bugs and security problems.
Each security report is acknowledged upon receipt, and the team works to verify the vulnerability and determine its severity. If confirmed, the development team then plans for a patch to fix the problem which can be committed to an upcoming release of the Gravity Forms software or it can be pushed as an immediate security release, depending on the severity of the issue.
For every release, an announcement is published by the Gravity Forms Leadership Team to the Gravity Forms blog listing the changes. Details of the vulnerability will be made available to trusted parties on request. Credit for the responsible disclosure of a vulnerability is given in the announcement to encourage and reinforce continued responsible reporting in the future.
Administrators of the Gravity Forms software see a notification on their site dashboard to upgrade when a new release is available. If administrators have automatic background updates enabled, Gravity Forms will be updated automatically.
Starting with version 1.9, Gravity Forms introduced automated background updates for all minor releases, such as 1.9.3 and 1.9.4. The Gravity Forms development team can identify, fix, and push out automated security enhancements for Gravity Forms without the site owner needing to do anything on their end, and the security update will install automatically. This is enabled by default on all new installations from version 1.9.2 onward.
Individual 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 by the development team, as well as running the latest stable release of Gravity Forms.
2013 OWASP Top 10
The Open Web Application Security Project (OWASP) is an online community dedicated to web application security. The OWASP Top 10 list focuses on identifying the most serious application security risks for a broad array of organizations. The Top 10 items are selected and prioritized in combination with consensus estimates of exploitability, detectability, and impact estimates.
The following sections discuss the APIs, resources, and policies that Gravity Forms uses to strengthen the core software and 3rd party plugins and themes against these potential risks.
A1 – Injection
There is a set of functions and APIs available in WordPress which Gravity Forms developers use in making sure unauthorized code cannot be injected, and help them validate and sanitize data. Best practices and documentation are available on how to use these APIs to protect, validate, or sanitize input and output data in HTML, URLs, HTTP headers, and when interacting with the database and filesystem. Administrators and Form Editors can also further restrict the types of file which can be uploaded via filters and settings.
A2 – Broken Authentication and Session Management
WordPress core software manages user accounts and authentication and details such as the user ID, name, and password are managed on the server-side, as well as the authentication cookies. Passwords are protected in the database using standard salting and stretching techniques. Existing sessions are destroyed upon logout for versions of WordPress after 4.0.
Gravity Forms utilizes WordPress authentication for session management alongside a simple implementation of OAuth 1 with HMAC-SHA1 signatures which is used by external clients for session-less connections to the Gravity Forms API.
A3 – Cross Site Scripting (XSS)
WordPress provides a range of functions which help Gravity Forms developers ensure that user-supplied data is safe. Trusted users, that is Administrators on a single WordPress installation, and site administrators in WordPress Multisite and users with the permission to edit forms, can publish unfiltered HTML or JavaScript as they need to, such as inside a form confirmation or field label. Untrusted users and user-submitted content is filtered by default to remove dangerous entities by escaping output and stripping tags as appropriate depending on the context.
A4 – Insecure Direct Object Reference
Gravity Forms often provides direct object reference, such as unique numeric identifiers of forms or entries. While these identifiers disclose direct system information, Gravity Forms』 rich permissions and access control system prevent unauthorized requests.
A5 – Security Misconfiguration
The majority of the WordPress and Gravity Forms security configuration operations are limited to a single authorized administrator. Default settings for Gravity Forms are continually evaluated at the development team level, and the Gravity Forms development team provides documentation and best practices to tighten security for server configuration for running Gravity Forms on a WordPress site.
A6 – Sensitive Data Exposure
WordPress user account passwords are salted and hashed based on the Portable PHP Password Hashing Framework. WordPress』 permission system is used to control access to private information such as entry details. Gravity Forms provides functions to help developers enforce authorization and also encourages the use of these functions throughout the documentation including examples of best practices.
A7 – Missing Function Level Access Control
Gravity Forms checks for proper authorization and permissions for any function level access requests prior to the action being executed. Access or visualization of administrative URLs, menus, and pages without proper authentication is tightly integrated with the authentication system to prevent access from unauthorized users.
A8 – Cross Site Request Forgery (CSRF)
WordPress uses cryptographic tokens, called nonces, to validate intent of action requests from authorized users to protect against potential CSRF threats. WordPress provides an API for the generation of these tokens to create and verify unique and temporary tokens, and the token is limited to a specific user, a specific action, a specific object, and a specific time period, which can be added to forms and URLs as needed. Additionally, all nonces are invalidated upon logout.
Gravity Forms utilizes this WordPress API to protect against potential CSRF threats.
A9 – Using Components with Known Vulnerabilities
The Gravity Forms development team closely monitors the few included libraries and frameworks Gravity Forms integrates with for core functionality.
If necessary, the development team may decide to fork or replace critical external components.
A10 – Unvalidated Redirects and Forwards
WordPress』 internal access control and authentication system will protect against attempts to direct users to unwanted destinations or automatic redirects. This functionality is also made available to plugin developers via an API, wp_safe_redirect().
Gravity Forms utilizes wp_safe_redirect().
Further Security Risks and Concerns
XXE (XML eXternal Entity) processing attacks
When processing XML, WordPress and Gravity Forms disable the loading of custom XML entities to prevent both External Entity and Entity Expansion attacks. Beyond PHP』s core functionality, Gravity Forms does not provide additional secure XML processing APIs for add-on authors.
SSRF (Server Side Request Forgery) Attacks
HTTP requests issued by WordPress are filtered to prevent access to loopback and private IP addresses. Additionally, access is only allowed to certain standard HTTP ports.
Gravity Forms uses the WordPress HTTP API for all HTTP requests.
Appendix
Core WordPress APIs
The WordPress Core Application Programming Interface (API) is comprised of several individual APIs, each one covering the functions involved in, and use of, a given set of functionality. Together, these form the project interface which allows plugins and themes to interact with, alter, and extend WordPress core functionality safely and securely.
While each WordPress API provides best practices and standardized ways to interact with and extend WordPress core software, the following WordPress APIs are the most pertinent to enforcing and hardening WordPress security:
Database API
The Database API, added in WordPress 0.71, provides the correct method for accessing data as named values which are stored in the database layer.
Gravity Forms always utilizes the Database API to access the database layer.
HTTP API
The HTTP API, added in WordPress 2.728 and extended further in WordPress 2.8, standardizes the HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP 1.1), and various other HTTP protocol implementations. The API standardizes requests, tests each method prior to sending, and, based on your server configuration, uses the appropriate method to make the request.
Gravity Forms utilizes the HTTP API for all HTTP requests.
Permissions and current user API
The permissions and current user API is a set of functions which helps verify the current user』s permissions and authority to perform any task or operation being requested, and can protect further against unauthorized users accessing or performing functions beyond their permitted capabilities.
Gravity Forms utilizes the permissions and user API to protect against unauthorized access.

Security Warning: merge tags as HTML attribute values

If your form confirmation is using a merge tag as a value for an HTML attribute, you may see the following warning:
Your confirmation message appears to contain a merge tag as the value for an HTML attribute. Depending on the attribute and field type, this might be a security risk.
Example:
Link
This can result in a Cross Site Scripting (XSS) vulnerability for most field types. The following field types are safe to use as values for HTML attributes: Calculation, Email, File Upload, Time.
Regardless of the field type, if you decide to continue, please ensure you enable confirmation sanitization using the gform_sanitize_confirmation_message filter. This will remove all potentially dangerous scripts and tags from your confirmation.

Section Break

SummaryCommon SettingsAdvanced SettingsNotesMerge Tags

Summary

The Section Break field allows you to add a content separator to your form to help organize groups of fields. This is a visual element rather than an actual data collecting form field. It is available under the Standard Fields section within the form editor.

Section Break field as displayed in the Field Library

Section Break field as displayed in the Form Editor.

Common Settings

This field only uses common field settings for the General and Appearance settings. For a description of each of the common field settings, refer to this article.

Advanced Settings

SettingDescriptionEnable Conditional LogicCreate rules to dynamically display or hide this section based on values from another field. Remember, to use conditional logic, you will need to first add any field supported by conditional logic (e.g. a drop down, checkboxes, etc). See note 1.

Notes

1. Conditional logic applied to a section applies to any field under that section too until a new section, a page break, or the end of the form is found.

Merge Tags

This field does not support merge tags.