Note: 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 analyzes and explains the Gravity Forms software development and its related security processes, and examines the inherent security built into the software. Decision makers evaluating Gravity Forms as a form design and management system or a web application framework should use this document in their analysis and decision-making, and developers can refer to it to familiarize themselves with the software’s security components and best practices.
The information in this document reflects the latest stable release of the software. Backward compatibility within a major version is a strong focus for the Gravity Forms development team, so this document should be considered relevant to recent versions of the software as well. Specific security measures and changes are noted as they have been added to the core software in specific releases. It is strongly encouraged to always run the latest stable version of Gravity Forms to ensure the most secure experience possible.
Executive Summary
Gravity Forms is a dynamic form management system that is used to power websites and web applications. It currently powers more than 5 million websites worldwide. 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 to address and mitigate common security threats, including the risks identified by the Open Web Application Security Project (OWASP) in the OWASP Top Ten, 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, and to recommend and document 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 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 Alex Cancado, Carl Hancock, and Kevin Flahaut. 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 leads architecture discussions and implementation efforts.
Version Numbering and Security Releases
Refer to the Gravity Forms Version Numbering article for detailed and up-to-date information on how releases are numbered, which release types update automatically, and how urgent fixes are delivered.
Version Backward Compatibility
Minor and patch releases within a major version maintain backward compatibility and preserve existing functionality. Major version updates do not maintain backward compatibility and may contain breaking changes.
For details on version numbering and update types, see Version Numbering Meaning.
Gravity Forms and Security
The Gravity Forms Development Team collaborates with security specialists to address issues in the software and its dependencies. For example, an arbitrary-file-upload vulnerability in the file upload field in versions 1.8.19 and earlier was resolved in version 1.8.20.
The Gravity Forms Leadership Team believes in Responsible Disclosure by alerting the development team immediately of any potential vulnerabilities. If you have discovered a security vulnerability, see Information for Security Researchers for how to report it.
Note: Gravity Forms customers should instead refer to How To Report a Security Issue. The Development Team communicates privately and works in a walled-off repository for tracking, testing, and fixing bugs and security issues.
Each security report is acknowledged upon receipt, and the team verifies the vulnerability and determines its severity. If confirmed, the development team plans to release a patch to fix the problem, which can be included in an upcoming release of the Gravity Forms software or pushed as an immediate security release, depending on the severity of the issue.
For every release, the Gravity Forms Leadership Team publishes an announcement on 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.
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. The Gravity Forms development team can identify, fix, and push out automated security enhancements without the site owner needing to do anything on their end, and the security update will install automatically.
Individual site owners can opt to remove automatic background updates through a 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.
OWASP Top Ten
The Open Web Application Security Project (OWASP) is an online community dedicated to web application security. The OWASP Top Ten focuses on identifying the most serious application security risks for a broad array of organizations. The items are selected and prioritized in combination with consensus estimates of exploitability, detectability, and impact estimates. OWASP revises the list periodically, and the Gravity Forms development team tracks the current edition along with other security issues that broadly affect our industry.
The following sections discuss the APIs, resources, and policies that Gravity Forms uses to strengthen the core software and third-party add-ons against the risks in the current list that are most relevant to a form management system.
Broken 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.
Gravity Forms often provides direct object reference, such as unique numeric identifiers of forms or entries. While these identifiers disclose direct system information, the rich permissions and access control system in Gravity Forms prevents unauthorized requests.
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 generating these tokens to create and verify unique, temporary tokens, which are limited to a specific user, action, object, and time period, and 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.
Unvalidated redirects and forwards
The internal access control and authentication system in WordPress will protect against attempts to direct users to unwanted destinations or automatic redirects. This functionality is also available to plugin developers via the wp_safe_redirect() API. Gravity Forms utilizes wp_safe_redirect()
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.
XXE (XML eXternal Entity) processing attacks
When processing XML, WordPress and Gravity Forms disable loading custom XML entities to prevent 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.
Software Supply Chain Failures
The Gravity Forms development team closely monitors the few libraries and frameworks it integrates with for core functionality.
If necessary, the development team may decide to fork or replace critical external components.
Cryptographic Failures
WordPress user account passwords are salted and hashed based on the Portable PHP Password Hashing Framework. The WordPress permission system controls access to private information, such as entry details. Gravity Forms provides functions to help developers enforce authorization and encourages their use throughout the documentation, including examples of best practices.
Injection
There is a set of functions and APIs available in WordPress that Gravity Forms developers use to prevent unauthorized code injection and to 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 files that can be uploaded via filters and settings.
Cross-Site Scripting (XSS)
WordPress provides a range of functions that 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.
Authentication Failures
WordPress core software manages user accounts and authentication, and user details such as the user ID, name, and password are stored on the server-side, along with authentication cookies. Passwords are protected in the database using standard salting and stretching techniques. Existing sessions are destroyed upon logout.
Gravity Forms utilizes WordPress authentication for session management alongside an implementation of OAuth 1.0a with HMAC-SHA1 signatures, which is used by external clients for session-less connections to the Gravity Forms API.
Further Security Risks and Concerns
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.
REST API Security
The Gravity Forms REST API v2 provides programmatic access to forms, entries, and submissions. It is disabled by default and must be explicitly enabled by an administrator under Forms → Settings → REST API.
Authentication
The REST API supports OAuth 1.0a with HMAC-SHA1 signatures, which is the recommended method and required for connections not made over HTTPS. Basic Authentication is also supported but must only be used over HTTPS, since credentials would otherwise be transmitted in plaintext. WordPress Application Passwords are supported as of Gravity Forms 2.4.21.4. Requests originating from a logged-in administrative session fall back to standard WordPress cookie authentication with nonces.
Access control
API keys are issued as a Consumer Key and Consumer Secret pair, tied to a specific WordPress user and scoped to read, write, or read/write permissions. Requests execute with that user’s Gravity Forms capabilities, so a user without the relevant capability cannot perform the corresponding action even with valid credentials. Capability requirements are filterable, allowing site owners to tighten or adjust access as needed. The form submission endpoint is a deliberate exception that does not require Gravity Forms capabilities, so that public forms can be submitted via the API.
For full details, see the REST API v2 Authentication documentation.
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 the 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 uses the Database API to access the database.
HTTP API
The HTTP API, added in WordPress 2.7 and further extended in WordPress 2.8, standardizes HTTP requests for WordPress. The API handles cookies, gzip encoding and decoding, chunk decoding (if HTTP/1.1), and various other HTTP protocol features. 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 that help verify the current user’s permissions and authority to perform requested tasks or operations, and can further protect against unauthorized users accessing or performing functions beyond their permitted capabilities.
Gravity Forms utilizes the permissions and user API to protect against unauthorized access.