Application security is the discipline of building and running software so that logins, sessions, and data handling resist misuse by outsiders.
It covers the whole application people use, such as a bank website, not only one programmatic interface beside it.
How it works
Builders decide how a session stays tied to the customer who signed in, how errors are shown without revealing secrets, and how a form treats input it did not expect.
Operators then watch the live bank site for abuse of those same paths after launch.
A gap in the application can let one customer see another customer's statements even when the network and the office doors are sound.
Fixing it is part of design and of the weekly running of the service, not a single purchase at the end.
Concrete examples
- A bank website session remains valid on a shared computer after the customer closes only the tab, and the next person sees the balance.
- An error page on a loan form prints a stack of internal details that show how the application stores applications.
- A statement download accepts an identifier that belongs to a different customer and returns that other file.
Protective measures
- End the session when the customer signs out, and also end it after a period of quiet on a shared computer.
- Show customers a plain error, and keep internal details in a log that only the operating team can read.
- Check on the server that the signed in customer is allowed to open the specific statement being requested.
- Review new bank features for these failures before release, and recheck them when a fix touches login or downloads.
Related articles
Readers who want more on a bank web application should open What is a security patch? next.
For day to day work on a bank web application, add What is a software patch? to the same reading list.
People who look after a bank web application compare this explanation with What are Private Access Tokens?.