OWASP Security Principles for CISOs, CSOs, AppSec & DevSecOps Teams

OWASP security principles provide a neat list of proactive controls for CISOs, CSOs, AppSec and DevSecOps teams working to develop secure web and API applications. But what is the Open Web Application Security Project (OWASP) model? How do the OWASP requirements and methodology contribute to information security standards? 

In this blog post, we define the OWASP risk assessment framework, explain the OWASP Top Ten, and outline how you can deploy Payara Server Enterprise to develop secure applications – including the pertinent areas from OWASP risks categories. 

What is the Open Web Application Security Project?  

OWASP stands for the Open Worldwide Application Security Project. The OWASP Foundation is the world’s largest nonprofit organization with a laudable aspiration of ending insecure software. It delivers this via global membership, conferences and workshops, and open-source projects that are highly regarded in the industry. 

These projects include the production of cybersecurity documentation, standards, and other tools that are used by the largest software vendors worldwide. This includes the OWASP Top 10 attacks against which application development teams need to harden their app and API security. 

What is the OWASP Top Ten? 

The OWASP Top 10 list is one of the most recognisable cybersecurity industry standards and references for development teams and web application security professionals worldwide. It provides a globally recognized consensus of the ten most recent and critical security risks to web applications. While there are 2013 and 2017 lists that are still referenced by some companies and software products, the 2021 list is the most recent, with a new list planned for release in 2025. 

The OWASP Top 10 – 2021 is as follows: 

1. Broken Access Control means that users can potentially gain unauthorized access to act in areas outside their intended permission levels 
2. Cryptographic Failures refers to when sensitive data is exposed due to a deficiency or lack of protection 
3. Injection describes how unvalidated or hostile data can be introduced into an application 
4. Insecure Design refers to architectural flaws in the design and development stages that cannot be fixed by subsequent implementation or security controls 
5. Security Misconfiguration relates to risks that are posed by missing, unnecessary, disabled, poorly set, insecure, or outdated configurations in an application 
6. Vulnerable and Outdated Components means software that is unsupported, obsolete, not regularly scanned, left unfixed, not upgraded or updated, or poorly configured 
7. Identification and Authentication Failures refer to breaks in confirming an application user’s identity and other session management credentials 
8. Software and Data Integrity Failures describe how insecure code and infrastructure can fail to protect against application integrity violations due to a reliance on content from untrusted sources 
9. Security Logging and Monitoring Failures concerns an application’s ability to detect, escalate, and respond to active breaches 
10. Server-Side Request Forgery (SSRF) security flaws can occur when an application fetches a remote resource without validation of the user-supplied URL 

For each of these security risks, OWASP provides information on: 

• The statistics of risk incidence rates 
• Its risk position and movement from the previously published list 
• A description and breakdown of what the risk means 
• Guidance on how to prevent the risk 
• Examples of risk attack scenarios 
• Relevant risk references (testing guides and cheat sheets) 
• Lists of risk maps and paths 

Other OWASP Projects 

There are other OWASP Top 10 lists, including the OWASP Top Ten Proactive Controls (2018), and the OWASP Top 10 for Late Model Applications (LLMs). The following two are the most relevant to application security and are worthy of your consideration in any robust application security posture. 

OWASP API Security Top 10 Security Risks 

The OWASP API Top 10 is a reference for the unique vulnerabilities and security risks of Application Programming Interfaces (APIs). 

OWASP Application Security Verification Standard (ASVS) 

The OWASP ASVS as another framework for testing web application technical security requirements, providing developers with a list of requirements they can use both for guidance building security controls in and as a metric for assessing security trustworthiness. 

OWASP and Related Security Standards 

Many other standards and organizations refer to OWASP’s Top 10 project, such as MITRE, Payment Card Industry Data Security Standards (PCI DSS), DISA-STIG, and the FTC. In turn, OWASP references two other well-known standards in its work. 

OWASP and NIST 800 

OWASP lists NIST’s Technical Guide to Information Security Testing and Assessment (NIST SP 800-115) as a one of its recommended penetration testing methodologies. It also refers to NIST guidelines in password policies the use of MFI and when giving advice on how to prevent Identification and Authentication Failures (OWASP Top 10 – Risk 7). OWASP discusses NIST 800-53 on security controls. 

OWASP and ISO 27001 

The International Organization for Standards’ Information security, cybersecurity and privacy protection – Information security management systems – Requirements (ISO 27001:2002) standard is listed as a “supporting reference” in OWASP’s Open Source Security Testing Methodology Manual (OSSTMM). It is most mentioned by OWASP in relation to API Security Risks. 

Developing Secure Applications with Payara Server Enterprise 

All our products come with essential features that help you harden the security of your application. One way we achieve this is by following industry standards such as the OWASP Top 10 and enhancing our products accordingly. 
If you are deploying a Jakarta EE web app, you will need to know what security settings you can configure in Payara Server Enterprise. We have listed these below and related each to the most relevant items from the OWASP Top 10 risk categories. 

Administering System Security 

System Security in Payara Server Enterprise is the practice of safeguarding information systems against unauthorized access, modification, or malicious attack.  
The relevant parts of the OWASP Top 10 risk categories are: 1 Broken Access Control, 5 Security Misconfiguration, and 7 Identification and Authentication Failures. 
The configurable System Security measures in Payara Server Enterprise are: 

• Authentication – Authentication mechanisms supported by Payara Server Enterprise include the Basic Authentication Scheme, as well as Form, Client-cert, and Digest. The Jakarta Security API provides an alternative mechanism for configuring the authentication type for applications. These authentication mechanisms determine whether to grant access to any entity, such as an application, component, or user. 
• Authorization – All authorization permissions are granted to the Payara Server Enterprise internal server code. Jakarta Authorization enables the setting up of third-party plug-in modules to establish authorization based on custom policies. This authorization determines what data users can access or operations they can perform after authentication based on roles. 
• Auditing – All authentication and authorization decisions are captured by Payara Server Enterprise using default and custom audit modules. These modules maintain audit trails that form the basis for evaluating security measures. 
• Firewalls – Payara Server Enterprise allows for firewall configurations including Remote Method and double firewall architecture to manage communications between networks. 
• Certificates and Secure Transport – When Payara Server Enterprise is installed, a self-signed digital certificate is generated in Jave Secure Socket Extension (JSSE) format for internal testing. This provides users and resources with a unique identity to enable secure and confidential communication. 

For further information, see Administering System Security, Secure Applications with Authentication and Authorization, and Security Auditing in Payara® Server Enterprise. 

Administering User Security 

The Payara Server Enterprise environment takes the authentication and authorization policies created under System Security (above) and enforces them on realms and groups. It does this by using the asadmin command-line utility. 
The relevant parts of the OWASP Top 10 risk categories are: 1 (Broken Access Control), and 7 (Identification and Authentication Failures). 

The configurable User Security measures in Payara Server Enterprise are: 

• Security Realms – These are also known as ‘security authentication realms’ or ‘security policy domains’. They define the scope over which Payara Server Enterprise enforces a common security policy. They include: the File realm; the Administration realm; the Certificate realm; the LDAP realm which can be enabled on the Payara Server Enterprise DAS); the JDBC and Digest realms which can be configured; and the Oracle Solaris realm. The Administration realm can be created, listed, updated, and deleted.  
• File Users – The File security realm is used to intergrade users into the Payara Server Enterprise environment. It establishes their credentials in a secure way, and enables them to access the applications and services to which they are entitled. New file users can be created, listed (as individual users or file groups), updated, and deleted. 

For further information, see Administering User Security. 

Administering Message Security 

The Payara Server environment enables the configuring of message layer security for SOAP web services. Message security allows the performance of web service end-to-end authentication at the message layer. Payara Server deploys SOAP Web services securely, with functionality configured in the client-side containers. 
The relevant parts of the OWASP Top 10 risk categories are: 5 (Security Misconfiguration) and 10 (Server-Side Request Forgery). 

The configurable Message Security measures in Payara Server Enterprise are: 

• Security Tokens and Security Mechanisms – These are communications protocols for applying security mechanisms to web services. These mechanisms include username tokens, digital signatures, and encryption. 
• Authentication Providers – This is the message layer of authentication processing that provides web service message security at the SOAP level client-side and server-side. 
• Message Protection Policies – These provide message security mechanisms for request and response message processing.  
• Application-specific Web Services Security – These functions are configured by defining the message-security-binding elements in the Payara Server Enterprise deployment descriptors of the application. 
• Message Security Administration – These administrative interfaces modify message protection polices and create new security provider configurations with different message protection policies. 

For further information, see Administering Message Security. 

Security in High-Availability Environments 

Security in high-availability environments can be administered using cluster and deployment groups. 
The relevant parts of the OWASP Top 10 risk categories are: (Security Misconfiguration) and 6 (Vulnerable and Outdated Components). 

The configurable High Availability measures in Payara Server Enterprise are: 

• Configuring certificates in cluster mode – Since self-signed certificates lack authority, Payara Server Enterprise provides users and resources with a unique identity to enable secure and confidential communication. 
• Dynamic Reconfiguration – This is when replicating the administrative commands executed on the domain administrative server (DAS) to a single server instance, cluster or group. 
• Understanding Synchronization – Configuration data for a Payara Server Enterprise instance must be synchronized when an instance is started or restarted. This data is located in the repository of the DAS and in a cache on the local host. 

For further information, see Administering Security in a High-Availability Environment. 

Managing Administrative Security 

Administrative security is managed by use of the secure administration feature of Pyara Server, also called secure admin. It provides a secure environment in which administrative communications cannot be corrupted or impersonated, and has a domain-wide setting. 
The relevant part of the OWASP Top 10 risk categories is: 7 Identification and Authentication Failures. 

The configurable Administrative Security measures in Payara Server Enterprise are: 

• Functions – The enable-secure-admin subcommand performs many functions related to enabling secure admin behaviour and adjusting configurations or settings. 
• Administration Accounts – Payara Server responds in different ways depending on whether one or multiple administration accounts exist. 
• Authentication Methods – The authentication methods used for secure administration include two-way and one-way certificate authentication, public certification, locally-provisioned passwords, and encryption. 
• Certificate Authentication – Certificate authentication is performed by means of private keys and self-signed public certificates. 
• Certificates Used – Self-signed or custom certificates can be used, depending on the level of trust required by clients. 
• Distinguished Names – As an alternative approach to the above certificate types, Payara Server allows the acceptance of admin requests when accompanied by an SSL certificate with a specified distinguished name (DN). 
• Unwanted Connections – The secure admin feature guards against unwanted connections in different ways depending on whether they are DAS-to-DAS and instance-to-instance, or remote client-to-instance. 
• Default Security – By default, admin clients provide empty or zero credentials, and none of the participants encrypts network messages. 
• Prerequisites – There are prerequisites for running secure admin that need to be initialized, installed, running or otherwise in existence. 
• Alternatives – An alternative to self-signed certificates for secure authentication and authorizations, existing admin usernames, and passwords can be used. 
• Creating local instances – Depending on whether local instances variant commands are used, secure admin can be enabled or disabled. 

For further information, see Managing Administrative Security. 

Running in a Secure Environment 

Running a secure environment is a wide topic that relates to several OWASP Top 10 categories. The relevant parts of the OWASP Top 10 risk categories are: 4 (Insecure Design), 5 (Security Misconfiguration), and all OWASP categories that are concerned with different failure types (2, 7, 8 and 9). 
Here are some general points for running Payara Server Enterprise in a secure environment: 

• Determining Security Needs – Before deploying Payara Server Enterprise and Jakarta EE applications in a production environment, security needs and measures must be determined. This includes especially the strategic resources that need protecting, who you are protecting them from, and what will happen if protections fail. 
• Installing Payara Server – Install Payara Server in a secure environment by enabling the secure administration feature. 
• Running on the Web Profile – Run applications on Payara Server Enterprise’s Web Profile rather than the Full Profile as this reduces overall installation risks. 
• Securing the Payara Server Host Machine – Take measures to secure the physical machine, the operating system, with all other hardware and software involved. 
• Securing Payara Server Enterprise – Payara Server Enterprise provides software tools for securing applications and subsystems that run on the server.  
• Securing Applications – Different applications deployed in the production environment will require their own security responsivities and actions. 

For further information, see Running in a Secure Environment. 

SSL Certificate Management 

Payara Server employs formatted Java Keystore files to manage SSL/TLS certificates for secure communications. A new SSL certificate can be added to the Payara Server Enterprise configuration files by adding in the Keystore or Truststore. Certificates can be loaded from multiple Keystores using the Admin Console or Asadmin CLI. Expired certificated can be removed by the same means. 
The relevant parts of the OWASP Top 10 risk categories are: 2 Cryptographic Failures, and 7 Identification and Authentication Failures. 

For further information, see SSL Certificate Management. 

Printing Certificate Data 

Printing information on SSL certificates for client certificate authentication by the Payara Platform is best achieved using the print-certificate asadmin subcommand.
The relevant parts of the OWASP Top 10 risk categories are: 7 Identification and Authentication Failures. 

For further information, see Printing Certificate Data. 

Find Out More 

Read our Tech Blog, to keep up to date with the latest data security legislation, regulations, and standards. Visit Payara Server Enterprise for a free trial of our application server to see how you can use our security features to help you work toward the OWASP Top 10 best practices for secure, containerized Jakarta EE applications.