Web applications and other pieces of software custom developed for/by the organization must adhere to strict security standards throughout the entire software lifecycle.

Control Type: Administrative/Technical

Control Function: Technical

Protects: Confidentiality, Integrity, Availability

Many organizations reach a point where they decide that developing a web application is necessary for their business objectives. Whether this be a public facing e-commerce site, an internal HR management system, or a collaborative employee Intranet site, there are a variety of motivations to develop and deploy a custom web application. Sometimes cloud Software as a Service offerings do not meet all the demands of the organization. Or the organization may simply want more granular control over the specific components of the app.

Smaller organizations will most likely outsource the development to a third party, while larger organizations might have internal teams dedicated to custom web and database development. Regardless of the procurement decision, the organization must set strict standards for security in the web application development process. In the 2020s digital landscape, web applications are increasingly chosen as the choice targets by threat actors instead of the network perimeter. With the explosion of AI based vibe coding, there are more examples of vulnerabilities going overlooked until it’s too late. To avoid this as much as possible, organizations must formalize a Secure Web Application Development Process to be adhered to throughout all stages of the web application lifecycle. If the web application is being developed by a third party, the organization must require adherence to chosen security requirements as part of the contract.

A standard lifecycle model for the secure development and use of web applications looks like the following:

  1. Defining: clearly understand and define the business requirements for the application.
  2. Designing: design the actual components and functionality of the system, using user stories as guidelines.  
  3. Development: code for the application is written
  4. Testing: the completed code is tested through penetration testing, vulnerability scanning, and user testing. The testing methods can be divided into functional testing (ensuring the application meets the business requirements), and security testing (ensuring the application complies with defined security requirements). Both dynamic and static testing can be used against the code, with a combination of both generally preferred.
  5. Secure Operations: the application is approved for distribution and the focus shifts to maintaining security as it is used; identifying new vulnerabilities and releasing patches.
  6. Disposal: the application is phased out when a new version is released. This usually involves removing the application from production and implementing a new one to replace it. The older application components can then be archived.

Many organizations find that developing and securing web applications is an entirely different beast than typical network and endpoint security. This is because it is. Web application security is its own field, with new concepts, components, and challenges puzzling even seasoned IT professionals.

To help keep the web application development/deployment process stable, rigorous documentation needs to be kept. Development phases, supply chain information, revisions, and security test results need to be collected and stored to provide a historical timeline of the process. Version control tools such as Git are almost unanimously used to track every revision of the application from start to finish.

When it comes to what exactly needs to be addressed in terms of web application security, there are some very common issues facing most apps today. Open Worldwide Application Security Project (OWASP) maintains a Top 10 list of the most critical web application security risks. As of late 2026, the OWASP Top 10 includes:

  1. Broken Access Control (no least privilege enforcement, privilege creep)
  2. Security Misconfigurations (un-hardened systems, default accounts and features left enabled)
  3. Software Supply Chain Failures (no version control, no validation of external libraries, no vulnerability scanning)
  4. Cryptographic Failures (weak encryption algorithms, no SSL/TLS, poorly stored private keys)
  5. Injection (no user input validation/sanitization, non-parameterized calls)
  6. Insecure Design (security has not been properly factored into the application design from the onset)
  7. Authentication Failures (no password policy, no account lockout measures, exposed session IDs)
  8. Software or Data Integrity Failures (use of untrusted libraries, plugins, or modules and no validation of external components from untrustworthy sources)
  9. Security Logging & Alerting Failures (absence of any logging/monitoring, no data retention, no log backups)
  10. Mishandling of Exceptional Conditions (applications are not equipped to withstand unusual situations, resulting in unstable performance and frequent crashes).

For an organization developing a new web application, the OWASP Top 10 is a good place to start when defining security requirements. However, organizations will likely need a more exhaustive guiding source for the web application security process. The international standard for this is ISO/IEC 27034-1, which provides a high-level overview for managing security in the web application development process.  

ISO/IEC 27034-1 defines two document categories that are used to inventory and manage necessary security controls/requirements for web applications:

  1. Organizational Normative Framework (ONF): master framework for application security controls and best practices. The ONF includes standard controls to address security risks such as the ones defined in the OWASP Top 10.
  2. Application Normative Frameworks (ANFs): subsets of the ONF for each individual application. Basically, an application’s ANF is the selected controls from the ONF that are applicable to the specific application.

To understand the application of these the ONF and ANF, understand that one ANF maps to one ONF. Every application has a selected ANF catalog that selects its control from the single ONF. However, the ONF has many ANFs underneath it, with each developed web application having its own unique ANF. If an organization is only developing one application, they will have just one ANF to track. However, if the organization later decides to develop more web apps, they will accumulate multiple ANFs. But there will always be just one ONF.

The development of web applications is a complex process that requires strict attention to security on every component and feature. Organizations need to be aware of the multitude of threats facing such applications. It is highly recommended to perform an individual risk assessment for the project and keep the development team, whether internal or external, regularly briefed on security concerns and requirements at every step.