Deutsch | English

PLYNT ℠ Certification

Improve Defenses and Maintain Constant Vigilance Against Attacks

PLYNT ℠ Certification Program

The PLYNT ℠ certification program is an award-winning security assurance program from PLYNT ℠ (the Paladion's security testing unit), which was launched in 2006 by software development companies, SaaS, PaaS, software providers, software service providers, and organizations involved in the development of their software employ their own web applications.

We have designed the PLYNT ℠ certification program for commercial and custom web applications so that we can design the penetration test according to your needs and certify your website from a security perspective. With the PLYNT ℠ certificate in hand, your product managers and developers can prove to customers that the applications conform to very strict security criteria and are well secured against attack.

The PLYNT ℠ certification program measures a each application's ability to defend itself against relevant and specific threats. The application is tested against a comprehensive set of global security and vulnerability standards and guidelines such as OWASP, SB1386, OSSTMM, SEC 17, SANS, CWE Top 25, SOX, WebAppSec, HIPAA and PCI DSS.

You Order

Placing the order can be done quite unbureaucratically through Email

We test

We’ll use the information you give us to determine the possible threats your app might be susceptible to. We’ll conduct the penetration test at your convenience and deliver a detailed, easy-to-read report that will give you a complete profile of your security vulnerabilities and the ways to fix them. That report serves as a starting point with solution pointers to secure your site.

You fix

Our report will give you all the guidance your development team will need to test our solutions to fix the vulnerabilities we’ve identified. If you encounter a problem or have any questions give us a call or email us..

We retest and certify

We’ve run the tests and your development team has had a chance to fix the problems. Once the new version is ready for testing, we will conduct a full regression test. If we find no vulnerabilities, we will issue you the PLYNT ℠ Certificate of good health. Any time you need us after that we’re only a phone call or an email away. We are always ready to conduct additional tests.

If you want to achieve high security levels through the lifecycle of your application for a modest investment then the PLYNT ℠ Certification Program is for you. And you can obtain the PLYNT ℠ Certificate at any stage of the process | when the application is in production, in QA testing or in beta.

How does it work ?

Our web application security testing service creates a benchmark against the latest version of the 14 point PLYNT ℠ certification criteria. Similarly the mobile applications must adhere to 10 criteria to meet the PLYNT ℠ certification standards.

PLYNT ℠ Certification Criteria


Web Applications

Mobile Applications

are reproduced below.

These represent a very stringent set of conditions, thereby ensuring the security of your applications to the fullest.

Web App Testing

The Certification Standard is Composed of 14 Criteria. These are organised into two sections.

Security Protection Criteria

“Security Protection Criteria” identifies the defences an application and the hosting environment must demonstrate to meet the certification standard.

Security Requirements Criteria

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

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.

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

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 regarding application architecture that could aid an adversary who is attempting to launch an attack against the application.

  • 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

    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:

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

Mobile App Testing

The Certification Standard is Composed of 10 Criteria

PLYNT ℠ Mobile App Testing Criteria

  • Defends against Business Logic Threats

    The application must demonstrate its defence against threats specified in a Threat Profile that has been developed specifically for the mobile application.

  • Defends against code tampering

    Self-signing the recompiled APP build can breach the trust of users, as it contains modified data. An attacker can upload the replica of the APP to the store with a relevant name, wherein the details of legitimate users get exposed.

  • Defends against the unauthorised usage of device resources

    The application must ensure that untrusted input is validated before it is used by any device resource. The application must not abuse the device resources.

    Operating Systems implement functionalities that use mobile OS-related features. The application must implement these features securely, without introducing vulnerabilities.

  • Protects against data leakage

    The application must demonstrate adequate measures to protect sensitive data from being accessed whenever the device is lost or stolen. The application must not store sensitive data in the local storage, APP installation and property files.

    The application must not leak data through channels such as the application cache, logs, temporary directories, etc. wherein the data is usually retained indefinitely.

  • Protects against popular server-side attacks

    The application must demonstrate, through testing, that it is not vulnerable to popular server-side attacks.

  • Protects sensitive data in transmission

    The application must take adequate measures to protect sensitive data from being stolen over the network. It must protect the data in transmission by implementing strong encryption.

  • Backend services and servers protected against known vulnerabilities

    Mobile applications connect to backend services in order to send and receive data. These services must be protected against vulnerabilities that are directly exploitable throughout the application.

    The backend server must be updated and protected against known vulnerabilities. The web service running on the server that houses the application must not be vulnerable to publicly known exploitable vulnerabilities.

  • No sensitive data in the APP build

    The application must not retain hardcoded data like passwords and encryption keys.

  • Strong code obfuscation and cryptography techniques

    The application’s source code must be protected against data leakage, while disassembling the application package.

  • Sernsitive activities are re-authenticated

    The application must re-authenticate the user before allowing the user to perform an operation involving sensitive data. Examples of operations involving sensitive data are Change Password, Payments and Transaction Approval..

Select our service for the type of risk you face

Speak to a Security Expert