Software is the attack surface
Most of the systems an organisation exposes to the world are applications: websites, APIs, mobile apps and the services behind them. Network firewalls cannot see inside an application request, so a flaw in application logic or input handling becomes a direct path to data. Application security is the practice of designing, building, testing and operating software so that those paths do not exist, or are found and closed before an attacker finds them.
What makes applications vulnerable
- Trusting input: treating data from users, other systems or files as safe and passing it into databases, commands, templates or file paths.
- Weak identity handling: flawed authentication, predictable sessions, missing authorization checks on individual actions or records.
- Exposed secrets and data: credentials in code, verbose error messages, sensitive data in logs or responses.
- Insecure components: libraries, frameworks and container images with known vulnerabilities, pulled in without review or kept long after fixes are published.
- Misconfiguration: debug modes left on, default accounts, permissive cross-origin settings, missing security headers.
- Design flaws: business logic that can be abused, such as applying a discount repeatedly or changing a price in the client.
Why fixing it late is expensive
A flaw found during design costs a conversation. Found during coding, it costs a few lines. Found in testing, it costs a ticket and a retest. Found in production by an attacker, it costs an incident, customer notification, regulatory exposure and the emergency rework of code under pressure. Shifting security earlier is not a slogan; it is the cheapest way to build secure software.
The secure development lifecycle at a glance
- Requirements: define security requirements alongside functional ones.
- Design: threat model the architecture and choose controls.
- Implementation: follow secure coding standards and use vetted libraries.
- Verification: automated and manual testing for security defects.
- Release: secure configuration and deployment through a trusted pipeline.
- Operations: monitoring, patching and incident response for the application.
Worked example
A small team builds a customer portal. In the requirements phase they write down that customers must only see their own orders, that passwords must meet a standard, and that all input is validated. In design they decide every order lookup will be scoped by the authenticated customer identifier on the server. In implementation they use a framework that parameterises database queries by default. In verification an automated scanner and a peer reviewer check that no endpoint returns another customer’s data. The portal launches without the two most common classes of flaw because each phase did a little work.
Common mistakes
- Treating security as a final test before release.
- Assuming the framework handles everything.
- Leaving security to a separate team that developers never speak to.
Action Step: For one application you work on, write down which of the six lifecycle phases currently include any security activity, and which include none.