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.
Plynt standard concerns itself only with High and Medium risk vulnerabilities of the application that violates the Plynt criteria. Even though Low risk vulnerabilities are not considered while evaluating an application's security against Plynt certification standard, they are identified during the test and reported.This document is organized into two parts:
- Part I defines and lists the certification criteria.
- Part II explains the logic and rationale of the criteria.
Part1: Plynt Certification Criteria
The certification standard is composed of 14 criteria. These are organized in two sections:
Section 1, "Security Protection Criteria" identifies the defenses an application needs 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.
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 "Guide to the Plynt Certification Criteria" section.
- Defend against a Threat Profile: The application must demonstrate that it defends
against the threats specified in a threat profile that has been developed specifically for the
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 the 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, pass phrases
and PIN codes. If the password or PIN used by the application has less than 10,000
possible values, then the application must protect against manual guessing attacks.
Note I: The criterion requires that even after a user logs out, the user's password, pass phrase and PIN must be protected from theft.
Note II: The criterion recognizes that there are social engineering methods that could be used to steal the password, pass phrase and PIN without access to the application. These are not within the scope of this criterion.
Note III: A 4-digit numeric PIN is an example of a weak secret with less than 10,000 possible values.
Note IV: The risk of password or PIN guessing varies depending on the predictability of the usernames used by the application.
- Secure password recovery implementation: If the application provides a password, pass phrase, PIN-recovery feature like 'forgot password' then it must protect against an adversary from recovering or resetting the password or PIN or pass phrase of legitimate users. In addition, the application should ensure that upon issuance of a new password, pass phrase or PIN, it is securely communicated to the user.
- 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, denial of service
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 the attacks that would lead to server compromise, which would eventually affect the web application.
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: The application must not hide sensitive data
in html comments or hidden form fields embedded in the pages.
- No sensitive data 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 application architecture that could aid an adversary when attempting to launch an attack against the application.
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 an operation 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: 13. 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 business sensitive information as well as session token(s) and authentication token(s).
- No sample or test applications: The server must not make available any sample or test application to remote users.
Get a printable copy of the Plynt Certification Criteria