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.
1. Part I lists and defines the certification criteria.
2. Part II explains the logic and rationale of the criteria.
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.
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.
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.
The application must take adequate measures to protect sensitive data from being stolen over the network.
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.
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.
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.
The application should ensure authentication and integrity checks for interactions with web client components.
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.
he application must not hide sensitive data in html comments or hidden form fields embedded in the pages.
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.
Note: The secrets in the above criterion refer to cryptographic keys, passwords and algorithms that are considered trade secrets.
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.
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).
The server must not make available any sample or test application to remote users.
Our quote contains the best price, the time estimate, and our
methodology; and we’ll mail you the quote in 24 hours