Mitigate OWASP Top 10 in Web Applications
Developers need to address the OWASP Top 10 security risks in web applications to enhance security.
Plain language
When you're building a website or an online service, you need to pay attention to the top security risks that can cause trouble, like data breaches or hacking attempts. If these risks aren't addressed properly, your site could be vulnerable to attacks that compromise your users’ information, damage your reputation, and cost you a lot of money.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Feb 2023
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentSection
Web application developmentOfficial control statement
The OWASP Top 10 are mitigated in the development of web applications.
Why it matters
Failing to mitigate OWASP Top 10 risks (e.g., injection, XSS, access control flaws) can cause web app compromise, data leakage and service disruption.
Operational notes
Bake OWASP Top 10 mitigations into SDLC: secure coding standards, threat modelling, SAST/DAST, dependency scans, and regular remediation of findings and retesting.
Implementation tips
- Developers should familiarise themselves with the OWASP Top 10 security risks. Start by reading the OWASP Top 10 list to understand the most common threats, such as injection attacks or data exposure, and know what each risk means for your application.
- The IT team should regularly test the web application for these risks. Use tools or hire experts to scan the website and simulate attacks to see if the website can resist these common threats. This will help you find and fix vulnerabilities.
- Managers should ensure developers receive security training. Organise workshops or online courses that explain the OWASP Top 10 and how developers can build security into their coding practices.
- Project managers should incorporate security checks into the development timeline. Add steps in the project plan where developers must review code for security risks and get sign-off before moving to the next phase of development.
- The security team should monitor and update the web application continuously. Keep track of updates from the OWASP community and ensure the website is updated to handle new threats as they arise.
Audit / evidence tips
- AskThe OWASP Top 10 awareness training records: Request documentation showing developers attended training sessions GoodIncludes recent training dates, comprehensive content, and full attendance
- AskTo see recent security assessments of the web application GoodShows regular, complete scans with identified issues addressed timely
- AskSecurity sign-off documents in project plans: Request documents detailing security reviews in development phases GoodWill show sign-offs with dates from relevant team members indicating security checks were completed
- AskRecords of recent security patches and updates applied GoodIncludes recent updates that correspond with identified risks
- AskIncident response reports: Request records of any past security incidents and how they were managed GoodWill show clear steps, responsible persons, and follow-up actions
Cross-framework mappings
How ISM-1850 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (3) expand_less | ||
| Annex A 8.25 | ISM-1850 requires developers to mitigate the OWASP Top 10 security risks when developing web applications | |
| Annex A 8.26 | ISM-1850 requires the OWASP Top 10 risks to be mitigated as part of web application development | |
| Annex A 8.28 | ISM-1850 requires that web application development mitigates the OWASP Top 10 security risks | |
| handshake Supports (1) expand_less | ||
| Annex A 8.29 | ISM-1850 requires the OWASP Top 10 to be mitigated in web application development | |
| link Related (1) expand_less | ||
| Annex A 8.27 | Annex A 8.27 requires secure architecture and engineering principles to guide how systems are designed and built | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.