Report a cybercrime, cyber security incident or vulnerability.
Report

What are you looking for?

You can search for keywords to find pages that can help you e.g. scam
First published: 03 Jul 2025
Last updated: 03 Jul 2025

Content written for

Large organisations & infrastructure
Government

Attachments

Software development fundamentals

Introduction to software development

This section applies to software development activities for traditional applications (including user applications and server applications), mobile applications, web applications and artificial intelligence applications. Additional sections of these guidelines should also be consulted depending on the type of software development being undertaken. For example, the web application development section should be consulted for additional controls applicable to web applications.

Development, testing, staging and production environments

Segregating development, testing, staging and production environments, and their associated data, can minimise the likelihood of faulty or malicious code being introduced into a production environment. Furthermore, protecting the authoritative source for software is critical to preventing malicious code being surreptitiously introduced into software.

Control: ISM-0400; Revision: 6; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Development, testing, staging and production environments are segregated.

Control: ISM-1419; Revision: 1; Updated: Sep-18; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Development and modification of software only takes place in development environments.

Control: ISM-1420; Revision: 5; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Data from production environments is not used in non-production environments unless the non-production environment is secured to at least the same level as the production environment.

Authoritative source for software

Software developers need to ensure that they are using a secure authoritative source for software as part of their development environment, as doing so can reduce the security risks related to unauthorised access to source code, source code tampering and other possible cyber supply chain attacks on software artefacts. In doing so, the authoritative source for software should be able to provide sufficient access control and event logging for access to, and modification of, any source code and software artefacts.

Control: ISM-2023; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
An authoritative source for software is established and maintained.

Control: ISM-2024; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The authoritative source for software is used for all software development activities.

Control: ISM-1422; Revision: 3; Updated: Sep-18; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Unauthorised access to the authoritative source for software is prevented.

Control: ISM-1816; Revision: 0; Updated: Dec-22; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Unauthorised modification of the authoritative source for software is prevented.

Issue tracking

To providing visibility into source code changes, and support traceability, software developers should be able to link all changes, including security updates, change or feature updates, or bug fixes to a request or decision that is documented within an issue tracking solution.

Control: ISM-2025; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
An issue tracking solution is used to link software development tasks to security issues and decisions, change or feature requests, programming issues, or bug fixes.

Software artefacts

Software artefacts can include compiled code (such as libraries and executables), configuration files and any other file consumed by the software development process. Software artefacts, both internally and externally developed, could include malicious code or specifically crafted vulnerabilities designed to be exploited at a later stage. To assist in preventing the introduction of malicious software artefacts into an authoritative source for software, all software artefacts should be scanned for malicious code, undergo security testing or both before being stored in the authoritative source for software.

Control: ISM-2026; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
All software artefacts are scanned for malicious code before being imported into the authoritative source for software, including all compiled code, third-party libraries and software components.

Control: ISM-2027; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
All software artefacts are verified by a digital signature, or a secure hash provided over a secure channel, before being imported into the authoritative source for software.

Control: ISM-2028; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
All imported or referenced third-party software artefacts are tested using static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) before being imported into the authoritative source for software and periodically throughout the software development life cycle.

Control: ISM-2029; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The authoritative source for software restricts the use and import of third-party libraries and software components to trusted sources.

Control: ISM-2030; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Scanning is used during commits to identify plain text or encoded secrets and keys, which are then blocked from being stored in the authoritative source for software.

Build solution

The build process for software can unintentionally allow vulnerabilities in software to make it into production environments. This security risk can be reduced by ensuring the build solution uses all available security features and that all automated tested is completed as part of the build process.

Control: ISM-2031; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Compilers, interpreters and build tools (including pipelines) that provide security features to improve executable file security are implemented and such security features are used.

Control: ISM-2032; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The build solution ensures that all automated testing is completed without warnings, alerts or errors before building software artefacts.

Secure software development

The use of Secure by Design principles and practices, including secure programming practices and either memory-safe programming languages (such as C#, Go, Java, Ruby, Rust and Swift) or less preferably memory-safe programming practices, along with threat modelling and mitigation of common security risks, is an important part of secure software development. In addition, providing mechanisms to assist in determining the authenticity and integrity of software, while configuring it in a secure manner, can assist with cyber supply chain security activities.

As part of secure software development, software should be designed and built to be Secure by Default, that is, the software is secure ‘out of the box’ with little to no additional setup or configuration required to achieve an adequate level of security. Importantly, all built-in security measures, such as multi-factor authentication and event logging, are included in the base product at no extra cost to consumers.

Control: ISM-2033; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
All software security requirements are documented, stored securely and maintained throughout the software development life cycle.

Control: ISM-2034; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Security design decisions are documented and reviewed throughout the software development cycle.

Control: ISM-2035; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Security roles, responsibilities and knowledge requirements required to support the software development life cycle are identified and documented.

Control: ISM-2036; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Security responsibilities for software developers are identified and documented.

Control: ISM-2037; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Software developers that lack sufficient cybersecurity knowledge and skills required for their projects or tasks undertake suitable training on secure software development and programming practices.

Control: ISM-2038; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
A software developer cybersecurity knowledge and skills register is implemented and maintained.

Control: ISM-0401; Revision: 8; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Secure by Design principles and practices are followed throughout the software development life cycle.

Control: ISM-1238; Revision: 6; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Threat modelling is used in support of the software development life cycle.

Control: ISM-2039; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The software threat model is reviewed throughout the software development life cycle to ensure it reflects the as-built software and any changes to the threat environment.

Control: ISM-2040; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Secure programming practices for the chosen programming language are used for software development.

Control: ISM-2041; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Memory-safe programming languages, or less preferably memory-safe programming practices, are used for software development.

Control: ISM-2042; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Secure by Default principles and practices are followed throughout the software development life cycle, including by ensuring that all built-in security measures are included and enabled in the base product at no extra cost to consumers.

Control: ISM-1780; Revision: 1; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
SecDevOps practices are used for software development.

Control: ISM-2043; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Software is architected and structured to support readability and maintainability.

Control: ISM-1922; Revision: 0; Updated: Jun-24; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The Open Worldwide Application Security Project (OWASP) Mobile Application Security Verification Standard is used in the development of mobile applications.

Control: ISM-1923; Revision: 0; Updated: Jun-24; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The OWASP Top 10 for Large Language Model Applications are mitigated in the development of large language model applications.

Control: ISM-1924; Revision: 0; Updated: Jun-24; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Large language model applications evaluate the sentence perplexity of user prompts to detect and mitigate adversarial suffixes designed to assist in the generation of sensitive or harmful content.

Control: ISM-1796; Revision: 1; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Files containing executable content are digitally signed by a certificate with a verifiable chain of trust as part of software development.

Control: ISM-1797; Revision: 1; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Installers, patches and updates are digitally signed or provided with cryptographic checksums as part of software development.

Control: ISM-2044; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Software has no default credentials; however, if credentials are required, they are created on first install by the installing organisation.

Control: ISM-2045; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Application backwards compatibility does not compromise any security measures or features.

Control: ISM-2046; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Where software allows user impersonation, sensitive data is not logged and appropriate permissions are set.

Control: ISM-2047; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Where software allows an authentication factor to be reset, the user is notified of the reset through a secondary channel.

Control: ISM-2048; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Where software supports multiple user roles, non-administrative users are prevented from altering their profile permissions or privileges.

Control: ISM-2049; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
When user permissions or credentials are changed, software forces all impacted users to re-authenticate.

Control: ISM-2050; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
When digital signatures are processed by software, they are validated against a certificate trust chain and checked for revocation using a Certificate Revocation List or with the Online Certificate Status Protocol.

Control: ISM-2051; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Software generates sufficient event logs to support the detection of cybersecurity events.

Control: ISM-2052; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Event logs produced by software ensure that any sensitive data is protected.

Control: ISM-1798; Revision: 2; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Secure configuration guidance, in the form of a hardening guide or loosening guide, is produced and made available to consumers as part of software development.

Control: ISM-2053; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
End of life procedures for software, covering how to remove the software and how to archive or destroy any user accounts and data, are produced and made available to consumers.

Software bill of materials

A software bill of materials is a list of open source and commercial software components used in software development. This can assist software developers in ensuring they are not using software components with known vulnerabilities. It can also assist in providing greater cyber supply chain transparency for consumers of software by allowing for easier identification and management of security risks associated with individual software components used by software.

Control: ISM-2054; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
If a software bill of materials is available for imported third-party software components, it is used during software development to ensure such software components have no known vulnerabilities.

Control: ISM-1730; Revision: 0; Updated: Dec-21; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
A software bill of materials is produced and made available to consumers of software.

Software build provenance

A software build provenance is a manifest that describes the software components used in the build process, the set of commands executed during the build process, any relevant environmental context for the build process and the materials that were generated by the build process. A software build provenance assists in providing greater cyber supply chain transparency for consumers by allowing for the build process to be verified and, if needed, recreated.

Control: ISM-2055; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
If a software build provenance is available for imported third-party software components, it is used during software development to ensure such software components are built to an appropriate standard.

Control: ISM-2056; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
A software build provenance is produced and made available to consumers of software.

Network application programming interfaces

Network application programming interfaces (APIs) can facilitate the exchange of data between computing devices. As such, common security risks associated with their use should be mitigated during their development, especially for network APIs that are accessible over the internet. In particular, this includes mitigating poorly secured network APIs that facilitate unauthorised modification of data or access to data not authorised for release into the public domain. In such cases, ensuring authentication and authorisation of clients is performed when clients call network APIs can assist in mitigating unauthorised modification of, or access to, data. Finally, centrally logging and analysing network API use can assist in detecting malicious behaviour and contributing to investigations following cybersecurity incidents.

Control: ISM-1818; Revision: 2; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Authentication and authorisation of clients is performed when clients call network APIs that facilitate modification of data and are accessible over the internet.

Control: ISM-2013; Revision: 0; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Authentication and authorisation of clients is performed when clients call network APIs that facilitate modification of data but are not accessible over the internet.

Control: ISM-1817; Revision: 2; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Authentication and authorisation of clients is performed when clients call network APIs that facilitate access to data not authorised for release into the public domain and are accessible over the internet.

Control: ISM-2014; Revision: 0; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Authentication and authorisation of clients is performed when clients call network APIs that facilitate access to data not authorised for release into the public domain but are not accessible over the internet.

Control: ISM-1910; Revision: 1; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Network API calls that facilitate modification of data, or access to data not authorised for release into the public domain, and are accessible over the internet, are centrally logged.

Control: ISM-2015; Revision: 0; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Network API calls that facilitate modification of data, or access to data not authorised for release into the public domain, but are not accessible over the internet, are centrally logged.

Software input handling

Many vulnerabilities in software are caused by a lack of secure input handling. As such, it is essential that software does not trust any input, such as website addresses and their parameters, Hypertext Markup Language (HTML) form data, cookie values, or request headers, without performing validation or sanitisation. Examples of validation and sanitisation include ensuring a telephone form field contains only numerals, ensuring data used in a Structured Query Language query is sanitised properly and ensuring Unicode input is handled appropriately.

Control: ISM-1240; Revision: 5; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Validation and sanitisation are performed on all input received over the internet by software.

Control: ISM-2016; Revision: 1; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Validation and sanitisation are performed on all input received over a local network by software.

Control: ISM-2057; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
All input validation rules are documented, matched in code and tested with both positive and negative unit testing or integration testing.

Control: ISM-2058; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Data sources and serialised data inputs are validated before being deserialised.

Control: ISM-2059; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
File uploads or input are restricted to specific file types, with malicious content scanning occurring prior to file access, file execution or file storage.

Software interaction with databases

Structured Query Language (SQL) injection attacks, facilitated by the use of dynamically generated queries, are a significant threat to the confidentiality, integrity and availability of database contents. Specifically, SQL injection attacks can allow malicious actors to steal database contents, modify database contents, delete an entire database or even in some circumstances gain control of the underlying database server. Furthermore, when database queries from software fail, they may display detailed error information about the structure of databases. This can be used by malicious actors to further tailor their SQL injection attacks.

Finally, centrally logging and analysing all queries to databases from software that are initiated by users can assist in monitoring the security posture of databases, detecting malicious behaviour and contributing to investigations following cybersecurity incidents.

Control: ISM-1275; Revision: 2; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
All queries to databases from software are filtered for legitimate content and correct syntax.

Control: ISM-1276; Revision: 5; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Parameterised queries or stored procedures, instead of dynamically generated queries, are used by software for database interactions.

Control: ISM-1278; Revision: 5; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Software is designed or configured to provide as little error information as possible about the structure of databases.

Control: ISM-1536; Revision: 3; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
All queries to databases from software that are initiated by users, and any resulting crash or error messages, are centrally logged.

Software security testing

Software security testing can assist software developers in identifying vulnerabilities in their software. In doing so, testing should be designed to be repeatable and scalable while ensuring vulnerabilities in software are identified and remediated as early as possible. Such software security testing should include SAST, DAST and SCA in order to achieve comprehensive test coverage. As part of software security testing, software developers may also wish to replicate testing within typical consumer environments. Furthermore, software developers may choose to use independent testing to assist with removing any potential for bias that might occur when they test their own software. Finally, software needs to be comprehensively tested for vulnerabilities during development, prior to all releases and periodically in order to attempt to identify any previously unidentified vulnerabilities.

Control: ISM-0402; Revision: 9; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Software is comprehensively tested for vulnerabilities, using SAST, DAST and SCA prior to its initial release, any subsequent releases and periodically in order to attempt to identify any previously unidentified vulnerabilities.

Control: ISM-2060; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Code reviews are utilised to ensure software meets Secure by Design principles and practices as well as secure programming practices.

Control: ISM-2061; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Software developer-supported security-focused peer reviews are conducted on all critical and security-focused software components.

Control: ISM-2062; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Unit testing and integration testing, covering both positive and negative use cases, are used to ensure code quality and security.

Vulnerability disclosure program

Implementing a vulnerability disclosure program, based on responsible disclosure, can assist an organisation to improve the security of their products and services as it provides a way for security researchers and other members of the public to responsibly notify them of vulnerabilities in a coordinated manner. Furthermore, following the verification and resolution of reported vulnerabilities, it can assist an organisation in notifying their customers of vulnerabilities that have been discovered in their products and services, and any patches, updates or vendor mitigations that should be applied.

A vulnerability disclosure program should include processes and procedures for receiving, verifying, resolving and reporting vulnerabilities disclosed by internal and external parties. In support of this, a vulnerability disclosure policy should be made publicly available that covers:

  • the purpose of the vulnerability disclosure program
  • types of security research that are and are not allowed
  • how to report any vulnerabilities
  • actions, and associated timeframes, upon notification of vulnerabilities
  • expectations regarding the public disclosure of vulnerabilities
  • any recognition or reward for finders of vulnerabilities.

Finally, the Australian Signals Directorate (ASD) encourages security researchers and other members of the public to responsibly report vulnerabilities directly to an organisation. However, ASD recognises that this is not always practical, initial attempts at communication may be unsuccessful or the person making the report may not wish to do so directly. In such cases, vulnerabilities can be reported to ASD as an independent coordinator. Note, under ASD’s limited use obligation, information voluntarily provided to ASD about vulnerabilities cannot be used for regulatory purposes.

Control: ISM-1616; Revision: 0; Updated: Aug-20; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
A vulnerability disclosure program is implemented to assist with the secure development and maintenance of products and services.

Control: ISM-1755; Revision: 1; Updated: Dec-22; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
A vulnerability disclosure policy is developed, implemented and maintained.

Control: ISM-1756; Revision: 1; Updated: Dec-22; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Vulnerability disclosure processes, and supporting vulnerability disclosure procedures, are developed, implemented and maintained.

Control: ISM-1717; Revision: 3; Updated: Sep-24; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
A ‘security.txt’ file is hosted for each of an organisation’s internet-facing website domains to assist in the responsible disclosure of vulnerabilities in the organisation’s products and services.

Reporting and resolving vulnerabilities

Following the identification of vulnerabilities in software, either via internal software security testing or external security researchers, it is important that they are publicly disclosed in a responsible and timely manner. This allows users of impacted software to determine their risk exposure as part of their own cyber supply chain risk management activities. In doing so, such vulnerabilities should be resolved in a timely manner. In support of this, root cause analysis should be performed and, to the greatest extent possible, entire vulnerability classes should be remediated.

If vulnerabilities cannot be resolved in a timely manner via patches or updates, advice should be provided on how, to the greatest extent possible, the likelihood of vulnerabilities being exploited can be reduced, the impact of vulnerabilities being exploited can be reduced or both.

Control: ISM-1908; Revision: 2; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Vulnerabilities identified in software are publicly disclosed in a responsible and timely manner, including with Common Weakness Enumeration and Common Platform Enumeration information.

Control: ISM-1754; Revision: 4; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Vulnerabilities identified in software are resolved in a timely manner.

Control: ISM-1909; Revision: 1; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
In resolving vulnerabilities, root cause analysis is performed and, to the greatest extent possible, entire vulnerability classes are remediated.

Software event logging

Centrally logging and analysing security-relevant software crashes and error messages can assist in monitoring the security posture of software, detecting malicious behaviour and contributing to investigations following cybersecurity incidents.

Control: ISM-1911; Revision: 2; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Security-relevant software crashes and error messages are centrally logged.

Further information

Further information on a secure software development framework can be found in National Institute of Standards and Technology Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.

Further information on Secure by Design and Secure by Default principles and practices can be found in the following publications:

Further information on secure programming practices is available from the Carnegie Mellon University’s Software Engineering Institute.

Further information on the need for memory-safe programming languages can be found the following publications:

Further information on mobile application security can be found in the OWASP Mobile Application Security Verification Standard version 2.1.0 publication.

Further information on large language model application security risks can be found in the OWASP Top 10 for Large Language Model Applications version 2025 publication.

Further information on artificial intelligence security risks can be found in ASD’s An introduction to artificial intelligence and Engaging with artificial intelligence publications.

Further information on artificial intelligence security risks can also be found in the following publications:

Further information on cyber supply chain transparency, and recommended content for a software bill of materials, can be found in the United States’ National Telecommunications and Information Administration’s The Minimum Elements For a Software Bill of Materials (SBOM) publication.

Further information on strong authentication can be found in the authentication hardening section of the Guidelines for system hardening.

Further information on software security testing can be found on OWASP’s DevSecOps Guidelines and Source Code Analysis Tools websites.

Further information on implementing a vulnerability disclosure program can be found in the following publications:

Further information on developing a vulnerability disclosure policy is available from the disclose.io project to assist an organisation with their implementation.

Further information on recommended contents for a ‘security.txt’ file is available to assist an organisation with their implementation.

Further information on reporting vulnerabilities to ASD as an independent coordinator, including ASD’s limited use obligation, is available from ASD.

Further information on event logging can be found in the event logging and monitoring section of the Guidelines for system monitoring.

Web application development

Introduction to web application development

This section describes the controls applicable to web application development and extends upon the prior software development fundamentals section.

Secure web application design and development

Web application frameworks can be leveraged by software developers to enhance the security of web applications while decreasing development time. These resources can assist in securely implementing complex software functions, such as session management, input handling and cryptographic operations. In addition, OWASP provides comprehensive resources for software developers that should be followed when developing web applications.

Control: ISM-1239; Revision: 4; Updated: Mar-22; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Robust web application frameworks are used in the development of web applications.

Control: ISM-0971; Revision: 8; Updated: Mar-23; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The OWASP Application Security Verification Standard is used in the development of web applications.

Control: ISM-1849; Revision: 0; Updated: Mar-23; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The OWASP Top 10 Proactive Controls are used in the development of web applications.

Control: ISM-1850; Revision: 0; Updated: Mar-23; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The OWASP Top 10 are mitigated in the development of web applications.

Control: ISM-2063; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
If supported, web application session cookies set the HttpOnly flag, Secure flag and the SameSite flag by default.

Control: ISM-2064; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Web application session cookies contain only digitally signed opaque bearer tokens.

Control: ISM-2065; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Web application session cookies using opaque bearer tokens that are not digitally signed use non-sequential random identifiers with a minimum of 128 bits of entropy, preferably 256 bits of entropy.

Control: ISM-2066; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Web application sessions are centrally managed server side.

Control: ISM-2067; Revision: 0; Updated: Jun-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Web applications that support Single Sign On equally support Single Logout.

Web security policy response headers

Web security policy response header measures, such as Content-Security-Policy, Hypertext Transfer Protocol Strict Transport Security and X-Frame-Options, can be applied by web browsers to help protect themselves. This is achieved by web server software specifying security policy in response headers which web browsers then apply.

Control: ISM-1424; Revision: 5; Updated: Mar-25; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Content-Security-Policy, Hypertext Transfer Protocol Strict Transport Security and X-Frame-Options are specified by web server software via security policy in response headers.

Web application interactions

Hypertext Transfer Protocol Secure (HTTPS) is the Hypertext Transfer Protocol secured by Transport Layer Security (TLS) encryption. The use of HTTPS for web applications ensures that interactions with web applications are confidential and that the integrity of such interactions are also maintained.

Control: ISM-1552; Revision: 0; Updated: Oct-19; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
All web application content is offered exclusively using HTTPS.

Web application programming interfaces

Web APIs can facilitate the exchange of data between computing devices. As such, common security risks associated with their use should be mitigated during their development.

Control: ISM-1851; Revision: 0; Updated: Mar-23; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
The OWASP API Security Top 10 are mitigated in the development of web APIs.

Web application output encoding

The likelihood of cross-site scripting and other content injection attacks can be reduced through the use of output encoding. In particular, output encoding is useful when external data sources, which may not be subject to the same level of input filtering, are output to users. The most common example of output encoding is the conversion of potentially dangerous HTML characters into their encoded equivalents, such as ‘<’, ‘>’ and ‘&’ into ‘&lt;’, ‘&gt;’ and ‘&amp;’.

Control: ISM-1241; Revision: 4; Updated: Mar-22; Applicability: NC, OS, P, S, TS; Essential Eight: N/A
Output encoding is performed on all output produced by web applications.

Further information

Further information on web application security can be found in the OWASP Application Security Verification Standard 5.0.0 and OWASP Top 10 Proactive Controls 2024 publications.

Further information on web application security risks can be found in the OWASP Top 10 2021 publication.

Further information on implementing HTTPS can be found in ASD’s Implementing certificates, TLS, HTTPS and opportunistic TLS publication.

Further information on using TLS in HTTPS can be found in the Transport Layer Security section of the Guidelines for cryptography.

Further information on web API security can be found in the OWASP API Security Top 10 2023 publication.

Was this helpful?
Yes this was helpful
No this was not helpful

Thanks for your feedback!

We welcome additional feedback below.

Rate this product’s level of technical advice:
Rate this product’s usefulness:
Rate the product’s quality of analysis:
Rate the product’s timeliness: