Is application security only a developer responsibility?

No. Development, operations and organizational decisions all affect it.

Does passing every test prove complete security?

No. Tests provide evidence within their scope and assumptions.

Does an AI application still need ordinary access controls?

Yes. Model capabilities do not remove the surrounding application's protection requirements.

AI Glossary / Data governance and quality / Advanced

Application security

Definition

Application security is the work of designing, building, testing, operating and maintaining applications to protect them against security failures and misuse. It concerns the application's behavior and the systems and processes on which that behavior depends. For an AI service, this includes the surrounding website, accounts, data handling and integrations as well as relevant model-related risks. It is a continuing responsibility, not a single product or a final test before launch.

What it means

An application can produce useful results while exposing information or allowing actions that users should not be able to perform. Security asks what the system must protect, who may do what and how those expectations are enforced. In an original glossary publishing example, readers may view published articles, editors may revise assigned drafts and publishers may release approved versions. A successful reading feature does not establish that these other boundaries work. The team needs explicit requirements and evidence about the behavior that matters, including what happens when a request should be rejected.

How it works

Teams translate protection needs into requirements, implement appropriate controls, evaluate them and respond when problems are found. NIST's Secure Software Development Framework organizes practices around organizational preparation, protecting software, producing secure software and responding to vulnerabilities. OWASP's Application Security Verification Standard provides a basis for specifying and testing web application controls. These resources support systematic work rather than a universal guarantee. In an original AI publishing service, the team can document access rules, examine changes that affect those rules and retain evidence from relevant checks. Findings need owners, appropriate priority and verification after correction.

Three practical examples

A publishing application checks that an editor is allowed to change the requested draft, rather than relying only on whether the editor is signed in.
An AI content service reviews how an external integration receives data and defines which information the integration is permitted to receive.
A website team records a discovered security defect, corrects the affected behavior and repeats the relevant checks before closing the finding.

Think of it this way

Think of a shared workshop with rules for access, equipment use, storage and maintenance. A strong front door helps, but the workshop also needs suitable arrangements inside and a way to address problems over time. The analogy illustrates a collection of responsibilities rather than a single barrier. For software, those responsibilities must be translated into precise behavior that can be examined and tested.

Worked example

Consider an original fictional glossary application with two roles and three actions. Readers may read published articles but may neither edit drafts nor publish articles. Editors may read published articles and edit assigned drafts but may not publish. This creates six role-action checks under the stated assumptions: three for readers and three for editors. The expected outcomes are three permissions and three denials. During testing, five checks behave as expected, but a reader can edit a draft. The observed pass count is 5/6, approximately 83.3%. That percentage does not mean the application is 83.3% secure: one failed boundary can have substantial consequences, and the six checks cover only this simplified rule set. After correction, all six pass when repeated. The result supports those particular behaviors for the tested configuration. It does not establish protection against every other failure, nor does it test whether one editor can alter another editor's unassigned draft.

Illustrative case study

In a fictional AI glossary project, the team initially tests whether users can log in and whether the editor screen works. A later review adds the six permission checks from the example and finds that a reader can invoke an editing operation without using the editor screen. The team corrects the underlying access decision and verifies the expected denials as well as permissions. It then adds separate checks for draft ownership because the first set did not cover that distinction. The scenario illustrates how explicit requirements reveal gaps in feature-oriented testing. The successful corrections are evidence about defined cases, not certification that the entire application is secure.

Common misconceptions and mistakes

Security is not established merely because ordinary features work. Signing in proves neither permission for every operation nor ownership of every resource. Another mistake is treating a scanner result or a short test list as complete coverage. A firewall can support protection, but it cannot substitute for every application decision. Security also continues after release as the application, its dependencies and its operating environment change. Finally, an AI model's useful or accurate responses do not establish that the surrounding application handles access, confidential information and external actions correctly.

Business use

For a new AI website, define the information and operations that matter before choosing individual controls. In the fictional publishing project, draft access and release authority are concrete requirements that owners can review. Keep evidence of relevant checks, track unresolved findings and explain their consequences in terms of the service. When an integration or feature changes, reassess the affected assumptions. This gives managers a clearer basis for release decisions than a generic assurance that security testing occurred. The amount and depth of evaluation should reflect the actual application and its risks, rather than the number of available tools.

Check your understanding

How many role-action checks are in the toy example?

Answer: Six.

How many initially pass?

Answer: Five.

Why is 83.3% not a security rating?

Answer: The checks cover a narrow set of behaviors and do not measure every risk or its consequences.

What additional distinction remains untested?

Answer: Whether an editor can modify an unassigned draft.

Why repeat checks after a correction?

Answer: To verify the intended behavior and detect relevant regressions in the tested scope.

Related terms

Application firewall
Secure software development
authorization
threat modeling
vulnerability management
security testing

Learn next

Define three roles for a fictional publishing service and specify their permitted actions. Add resource ownership to the rules, then identify checks that the simpler role-only table would miss. Explain what passing those checks would demonstrate and what would remain outside their scope.

Sources

NIST, Secure Software Development Framework project overview: https://csrc.nist.gov/projects/ssdf OWASP, Application Security Verification Standard project overview: https://owasp.org/projects/asvs The role-action matrix, workshop analogy and glossary project are original educational illustrations. The cited overview pages support the frameworks' purposes; this entry is not a full assessment against either framework or a claim of certification.

Previous: Application programming interface endpoint Next: Apprenticeship Learning