Plynt Certification Criteria

Please make it: Version 5.0, Effective Date: Sep 2020

The awarding of the Plynt Certificate establishes that a web application has adequate measures to guard against remote adversaries and protect against a wide range of threats, including the threats and vulnerabilities documented by
organizations like OWASP, WASC and SANS.

This document defines the Plynt Certification Standard. It details the criteria that an application must meet in order to be awarded the Certificate.

This document is organized into two parts:

1. Part I lists and defines the certification criteria.
2. Part II explains the logic and rationale of the criteria.

The certification standard is composed of 14 criteria. These are organized into two sections:

Section 1, “Security Protection Criteria” identifies the defenses an application and the hosting environment must demonstrate to meet the certification standard.

Section 2, “Security Requirements Criteria” specifies the features, characteristics and behavior an application must maintain to enhance its security and meet the certification standard.

For explanation of the rationale behind the criteria, refer to the Guide to Certification Criteria.

The previous version of the criteria is archived here.
Click here for Plynt Certification Criteria for Mobile Applications.

Section 1 : Security Protection Criteria

Safe Against Popular Attacks

The application must demonstrate that it is not vulnerable to popular attacks.

Note: A list of the popular attacks we test for is present under the “Guide to the Plynt Certification Criteria” section.

Defend Against Threat Profile

The application must demonstrate that it defends against the threats specified in a threat profile that has been developed specifically for the application.

Note I: A threat describes the goal of an adversary. According to the National Information Systems Security Glossary, a threat is any circumstance or event that has the potential to harm an information system through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.

Note II: The threat profile is a list of all possible threats an application faces, but in this criterion we focus on threats related to business and authorization rule violations,because other threats are covered by the rest of the criteria.

Protect Sensitive Data in Transmission

The application must take adequate measures to protect sensitive data from being stolen over the network.

Protect Passwords from Theft and Guessing Attacks

The application must demonstrate that a remote adversary cannot steal or guess user passwords and passphrases. At a minimum, the application must enforce a minimum length of 8-character alphanumeric passwords.

Note I: The criterion requires that even after a user logs out, the user’s password or passphrase must be protected from theft.

Note II: The criterion recognizes that there are social engineering methods that could be used to steal the password or passphrase without access to the application. These are not within the scope of this criterion.

Note III: The risk of password guessing varies depending on the predictability of the usernames used by the application.

Secure Password Recovery Implementation

If the application provides a password recovery feature like ‘forgot password’, then it must protect against an adversary from recovering or resetting the password of legitimate users. In addition, the application should ensure that issuance of a new password is initiated after an alternate authentication mechanism. The application should implement a secure mechanism for issuing a new password that should be short-lived and of one-time use only.

Note I: An alternate authentication mechanism may include implementations like security questions, or one-time passwords sent to a user-owned device like mobile phone or other token devices.

Note II: A secure mechanism for password issuance entails the use of tokenized links, temporary passwords, and SSL communication while resetting the password.

By password we mean any secret that is used during an authentication process, for example, passphrase, PIN, passcode and passkey, etc.

Secure the Hosting Server Directly Accessible by the Users

All services that a user can reach must be securely configured and patched to prevent leakage of sensitive information, unauthorized access, buffer overflow, remote code execution, and other publicly known exploits.

Note I: This criterion includes securing all directories, backup, log and configuration files. Configuration files include OS, web server and application configuration files.

Note II: Along with the HTTP(s) service on which the application is accessible, this criterion mandates protection of all the non-HTTP(s) services like SSH, RDP, FTP, etc. against attacks that would lead to server compromise, which would eventually affect the web application.

Secure Application's Interaction with Web Client Components

The application should ensure authentication and integrity checks for interactions with web client components.

Note: The security of interactions specified in this criterion includes cross-domain origin checks and session management checks for web client components like Javascript, applets, Flash, HTML5, and Web sockets.

Section 2 : Security Requirements Criteria

Sensitive Data Not Stored on the Client

The application must not store sensitive data on the client machine in easily accessible locations.

Note I: Easily accessible locations include the browser cache, the browser history, web storage, other browser menus and persistent cookies on the client machine.

Note II: The browser memory is not considered an easily accessible location for this criterion.

Sensitive Data Not Hidden in Pages
Sensitive Data not Hidden in Pages

he application must not hide sensitive data in html comments or hidden form fields embedded in the pages.

No Sensitive Data in Error Messages
No SensitiveData in Error Messages

The application must not reveal sensitive information in error messages.

Note: Sensitive information includes not only business-sensitive information but also details regarding application architecture that could aid an adversary who is attempting to launch an attack against the application.

Code Obfuscation and Cryptography for Secrets
Code Obfuscation and Cryptography for Secrets

If web client technologies like Javascripts, Applets or ActiveX controls contain secrets, they must use strong code obfuscation and cryptography techniques to protect the secrets.

Note: The secrets in the above criterion refer to cryptographic keys, passwords and algorithms that are considered trade secrets.

Re-Authentication Required for Sensitive Activities

The application must re-authenticate the user before allowing the user to perform an operation involving sensitive data. A few examples of operations involving sensitive data are “Change Password”, “Transfer Funds” and “Transaction Approval”.

Note: This criterion does not apply to the special case where the user has forgotten the password and resets the password using the application’s password recovery or “Forgot Password” feature.

No Sensitive Data in Requests to External Entities
No Sensitive Data in Requests to External Entities

If the application maintains links to external entities i.e. sites, web services and web sockets, it must not disclose any sensitive data other than that required to conduct the operation with the external entity.

Note: Sensitive data, as used in this criterion, include personal identity, personal health and payment card information, as well as session token(s) and authentication token(s).

No sample or test applications:
No Sample or Test Applications

The server must not make available any sample or test application to remote users.


Download Icon

Get a Printable Copy of the Plynt
Certification Criteria


Certification Criteria

Request a Proposal

Our quote contains the best price, the time estimate, and our
methodology; and we’ll mail you the quote in 24 hours

Start typing and press Enter to search