How to Build a Secure Customer-Facing Web Application: A Checklist for Australian Businesses

A secure customer-facing web application is designed with its threats in mind, enforces authentication and authorisation on every request, treats all input as untrusted, keeps secrets and dependencies under control, collects and keeps only the data it needs, logs what matters, and ships through a tested release process, then stays maintained. In Australia, it should also support your privacy obligations and data breach response. No application is completely secure; the aim is to reduce risk and recover well.

This checklist is for business owners and product managers commissioning a custom application, customer portal, booking system, marketplace, SaaS product or any web app that holds customer accounts and data, and for the developers who build them. It complements website security for Australian small businesses, which covers operating a site and mapping controls to the Essential Eight.

This article is not a security certification or a substitute for a professional security assessment. It is a practical baseline to discuss with your developers and testers.

A threat model is a structured conversation about what could go wrong. It does not need special tools. For each feature, ask four questions: what are we building, what can go wrong, what will we do about it, and did we do a good job?

The OWASP Top 10 is a widely used awareness list of the most critical web application security risks. The 2025 edition (OWASP) lists:

Most serious application breaches are authorisation failures, not clever hacks. Every request that reads or changes data must check, on the server, that this user may do this action on this specific object.

Supply chain. Modern applications are mostly third-party code. Software Supply Chain Failures is now third in the OWASP Top 10. Keep an inventory of dependencies, pin versions, use lockfiles, scan for known vulnerabilities in the build pipeline, remove unused packages and update on a schedule. Protect the build pipeline and repository with MFA and least privilege. Our guide to AI-generated code security covers extra checks when coding assistants add dependencies.

Secrets. Never put API keys, database passwords or tokens in source code or client-side bundles. The same applies to keys for integrations such as accounting or CRM APIs; see API integration for Australian businesses. Use a secrets manager or your platform's encrypted environment variables, give each secret the minimum permissions, rotate them, and scan repositories for leaked secrets.

The safest data is data you never collected. For each field, ask whether the application needs it, for how long, and who should see it.

You cannot respond to what you cannot see. Log security-relevant events (sign-ins, failures, permission changes, admin actions, data exports) without logging passwords, tokens or unnecessary personal data. Send logs somewhere attackers cannot easily alter, set alerts for suspicious patterns and review them.

Write an incident response plan before launch (the website security checklist includes an incident sequence): who decides, how to contain, how to preserve evidence and how to communicate. If your business is covered by the Privacy Act, the Notifiable Data Breaches scheme requires assessing suspected eligible breaches and notifying the OAIC and affected individuals where serious harm is likely; the OAIC received 1,205 notifications in 2025 (OAIC). Businesses with annual turnover over A$3 million must also report ransomware or cyber extortion payments to ASD within 72 hours (Home Affairs).

The OWASP Application Security Verification Standard (ASVS) turns these practices into testable requirements. Version 5.0 was released in 2025 and keeps three levels of increasing assurance (OWASP ASVS). Many business applications aim for level 2, with level 3 for the highest-risk systems, though the right level depends on your data and threats. Agreeing a level in the contract gives both sides a shared, checkable definition of 'secure enough'.

ASD's Secure by Design guidance encourages technology manufacturers to build security in from the start and to make secure behaviour the default (ASD). The Essential Eight remains a sound baseline for the systems around your application (ASD).

This example is hypothetical. An allied health group commissions a portal where patients see appointments, invoices and exercise plans. As a health service provider, it is covered by the Privacy Act.

The threat model identifies account takeover and access to other patients' records as the top risks. The team uses a managed identity service with MFA and strong recovery, enforces record-level authorisation with automated tests that try to read other patients' data, keeps clinical notes out of notifications and logs, hosts in an Australian region with documented support access, and agrees ASVS level 2 as the requirement. An independent test is scheduled before launch, and the incident plan includes NDB assessment steps.

For specific application types, see customer portals, booking systems and marketplaces. For mobile, see mobile app security. For generic depth, see building a secure business website and payment security.

Application security: OWASP Top 10:2025; OWASP ASVS; RFC 9700, OAuth 2.0 security best current practice; W3C, what's new in WCAG 2.2.

Australian guidance and obligations: ASD, Secure by Design; ASD, Essential Eight; OAIC, APP 11; OAIC, NDB statistics 2025; Home Affairs, ransomware payment reporting factsheet.

ASVS 5.0 and ASD Secure by Design details were confirmed via secondary summaries. The checklists and example are ours. This is not a security certification, a substitute for a professional assessment, or legal advice.

Building a secure customer-facing web application is a set of habits, not a feature: threat model, enforce authorisation everywhere, use proven identity, handle input safely, manage dependencies and secrets, minimise data, log and monitor, test before every release and keep maintaining. Agree a standard such as an ASVS level with your developers, and plan for incidents before launch. For testing and incident readiness after launch, see web application penetration testing and cyber incident response planning; for APIs specifically, API security best practices.