---
title: "AppSec Shared Security Model: It Really Is Everyone’s Responsibility"
description: AppSec isn't just for security teams. Understand the shared security model and how it can improve your application security posture.
image: https://true-positives.com/hubfs/AppSec-Shared-Security-Model-It-Really-Is-everyone%E2%80%99s-Responsibility-header.webp
---
[Skip to content](https://true-positives.com/appsec-blog/appsec-shared-security-model-it-really-is-everyones-responsibility#main-content)
[](https://true-positives.com/?hsLang=en)
- Resources
- [Vulnerability Atlas](https://vulnerability-atlas.true-positives.com/index.html)
# AppSec Shared Security Model: It Really Is Everyone’s Responsibility
.jpg)
[Brian Pavicic March 29, 2022](https://true-positives.com/appsec-blog/author/brian-pavicic)
- 7 mins
## What AppSec Can Learn from Cloud Security
In cloud computing, some of the responsibility for security lies with the cloud provider, and some lies with the cloud account owner. This shared security model can be unclear compared to the days when companies ran their own data centers—you have to expect to have some crossover of responsibility. Software security works the same way.
## What a Shared Security Model Means
Even in small software products, there can be cases where security is pushed to the end user, down to the user interface, or even reside on the backend service. To demonstrate how this works, let’s look at a simple example application that:
- Ingests data
- Displays the data in a UI
- Allows another user to export the data to a CSV
Even if that’s all it does, there’s already a lot of complex security at work. We’ll walk through a few of the possible classes of vulnerability and investigate which component is responsible for the security, why it is, and recommendations for what the component can do.
## Cases of Server Side Responsibility for AppSec
### SQL Injection
Description: Upload data into a SQL database.
Input: The inputs can be CSV, JSON, or XML. The source of the data can be from a user file upload, REST API Call, or typed into a UI.
Output: Data is loaded into the database.
Assumptions: Data is validated to conform to business rules. Some of the fields allow content of any kind.
Image credit to [SQLshack](https://www.sqlshack.com/sql-injection-detection-and-prevention/)
The security control needs to be implemented in the backend prior to storing the data, since it has more knowledge of the storage methodologies and can provide the most accurate controls. It can do this by analyzing the files for input validation, then building the database queries with [parameterized queries](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) to prevent any crossover between the data plane and the control plane of the SQL commands.
### Cross Site Scripting
Description: The User Interface requests data from the backend that is stored in a database.
Input: A returned web page with a content type of “application/html”.
Output: A web browser is to display the content.
Assumptions: This is the old school style of displaying data. The backend server isn’t using a REST API. The data being returned was validated for complying with business requirements.
The responsibility here lies with the backend that generates the HTML. This servlet request must use valid HTML escaping techniquest to protect the client. In this case, the client has no opportunity to protect itself because it has no concept of the data and control planes in the page sent back from the server.
### CSV Injection Attack - Backend Responsibility
Description: The User Interface uploads a CSV to be processed by the backend. The file can either be saved or re-generated to be viewed by support staff.
Input: A CSV file.
Output: The data is uploaded. Success is irrelevant. The file can be saved or not.
Assumptions: The support staff has the ability to generate or pull the CSV.
In this case, we know how the data will be used. The only reason to view it is to evaluate whether it’s accurate or what might have triggered an error. As a result, we can expect that there must be some protection for the support staff.
This can be done in a few ways:
1. Restrict or train support staff to use a simple text-based tool to view the data.
2. Prevent macro execution in more complex spreadsheet tools.
3. Encode the CSV appropriately to provide more protection, if the data is returned from an API endpoint which only the support staff can access.
## Cases of User Responsibility for AppSec
### Cross Site Scripting
Description: The User Interface requests data from the back-end that is stored in a database. The goal is to display it in a grid.
Input: Data is returned from the application using “application/json”.
Output: JSON format of data.
Assumptions: The backend is a REST API which was designed to speak to many types of clients. The calling client is a React front end. The data being returned was validated for complying with business requirements.
Here, there’s no guarantee on what the end client ultimately is, which makes it hard to determine appropriate security decisions. Any of the data being sent to the calling client could be made inaccurate by the API encoding it. The UI or user needs to perform the appropriate security protections.
### CSV Injection Attacks
Description: The User Interface requests data from the back-end that is stored in a database for downloading a CSV.
Input: Data is returned from the application using “application/csv” with the appropriate content disposition header.
Output: A downloaded file with the output.
Assumptions: The backend is a REST API which was designed to speak to many types of clients. The calling client is a React frontend. The data being returned was validated for complying with business requirements.
In this complex attack, the CSV files are opened in various spreadsheet apps and execute macros. [OWASP](https://owasp.org/www-community/attacks/CSV_Injection) even notes that these vulnerabilities are often excluded from bug bounty programs, but this doesn’t mean that third party pen testers won’t try to report it. Like the JSON dataset, it’s unknown what will read the data or how it’ll be used. So while it would be expected that the client would be responsible for securely reading the data, it would also be wise to provide guidance to the end user receiving the file.
## Cases of Cloud Owner Responsibility for AppSec
### Access Control Bypass
Description: A CSV file with sensitive data resides on a cloud storage device (e.g. S3 bucket)
Input: A CSV file.
Output: The data is successfully uploaded to the cloud storage.
Assumptions: Cloud storage access set to public, but naming scheme is complex
Authentication and authorization controls can be cumbersome. Sometimes, software owners try to create security through obscurity so they can have fewer interactions with IT admins and reduce complex controls. In this case, anyone can access a file at any time, so cloud owners must take responsibility by implementing appropriate access controls, standards, infrastructure as code, and automation.
## Cases of Cloud Platform Responsibility for AppSec
### Server Side Request Forgery
Description: Leveraging automation and cloud services in a shared tenant environment.
Input: A cloud service which requires a URL.
Output: The service is running on shared resources within the cloud platform.
Assumptions: The service runs as expected.
[Autowrap](https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/) is an example where the cloud platform itself is ultimately responsible for the security control. While there are things an application owner could do to prevent the type of attack that took place, ultimately the cloud platform should have provided better protections around unauthorized access to other tenants’ information.
## Fewer Assumptions Lead to Better AppSec
Many systems and people use and have access to any given piece of software, with more complexity and interconnectivity getting added all the time. With so many variables in place, adopting a shared security model for AppSec which has more overlap and fewer assumptions is vital for everyone involved.
And this means that software security professionals, whether they’re the DevSecOps team working with developers, a third party penetration tester coming in after the fact, or a vendor of software tools, must all adapt to this new model too.
Unsure of How Your AppSec Stacks Up?
The software security experts at True Positives keep up with these changes to advise and consult on AppSec, connect you with automation tools that help you avoid vulnerabilities, and manually test environments for breaches.
Contact us today for a [free 1-1 AppSec consultation.](https://true-positives.com/get-started)
.jpg)
### Brian Pavicic
Brian Pavicic founded True Positives to deliver comprehensive application security testing through cost-effective AppSecVar and managed service solutions. As an early member of @stake, he contributed to the development of modern application security practices. Over the past decade, Brian has focused on integrating automated tools with expert manual inspection to help organizations build digital trust efficiently and effectively.
[mailto:brian_pavicic@true-positives.com](mailto:brian_pavicic@true-positives.com)
## Latest posts
- [ALL POSTS](https://true-positives.com/appsec-blog/all)
[](https://true-positives.com/?hsLang=en)
[Managed AppSec](https://true-positives.com/managed_appsec_mssp) [In-House AppSec Support](https://true-positives.com/direct-platform-licensing)
[PRO Services](https://true-positives.com/appsec-pro-services) [Why T+](https://true-positives.com/why-true-positives)
[Resources](https://vulnerability-atlas.true-positives.com/index.html) [Contact Us](https://true-positives.com/contact-truepositives)
© 2026 True Positives, LLC. All rights reserved.
```json
{
"@context" : "https://schema.org",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Brian Pavicic",
"url" : "https://true-positives.com/appsec-blog/author/brian-pavicic"
},
"dateModified" : "2024-03-20T23:10:09.798Z",
"datePublished" : "2022-03-29T18:30:00.000Z",
"headline" : "AppSec Shared Security Model: It Really Is Everyone’s Responsibility",
"image" : [ "https://true-positives.com/hubfs/AppSec-Shared-Security-Model-It-Really-Is-everyone%E2%80%99s-Responsibility-header.webp" ],
"mainEntityOfPage" : {
"@id" : "https://true-positives.com/appsec-blog/appsec-shared-security-model-it-really-is-everyones-responsibility",
"@type" : "WebPage"
},
"publisher" : {
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject",
"url" : "https://true-positives.com/hubfs/HubSpot%20Header%20Logo%20-%20500x125.png"
}
}
}
```
```json
{
"@context" : "https://schema.org",
"@type" : "Organization",
"address" : {
"@type" : "PostalAddress",
"addressCountry" : "US",
"addressLocality" : "Chehalis",
"addressRegion" : "Washington",
"postalCode" : "98532",
"streetAddress" : "110 Villageway Drive"
},
"contactPoint" : [ {
"@type" : "ContactPoint",
"areaServed" : "US",
"availableLanguage" : "English",
"contactType" : "Sales",
"telephone" : "+1-206-854-8999"
}, {
"@type" : "ContactPoint",
"areaServed" : "US",
"availableLanguage" : "English",
"contactType" : "Sales",
"telephone" : "+1-404-314-3929"
}, {
"@type" : "ContactPoint",
"availableLanguage" : "English",
"contactType" : "Customer Support",
"email" : "tplus-support@true-positives.com"
}, {
"@type" : "ContactPoint",
"availableLanguage" : "English",
"contactType" : "General Inquiries",
"email" : "contact@true-positives.com"
} ],
"description" : "True Positives is a trusted AppSec MSSP delivering expert-led DAST and automated vulnerability scanning—reducing risk, eliminating false positives, and cutting overhead without compromising security.",
"email" : "info@true-positives.com",
"logo" : {
"@type" : "ImageObject",
"url" : "https://true-positives.com/hs-fs/hubfs/managed-application-security-testing-true-positives-logo.jpg?width=640&height=160&name=managed-application-security-testing-true-positives-logo.jpg"
},
"name" : "True Positives",
"sameAs" : [ "https://www.linkedin.com/company/truepositives/", "https://www.facebook.com/truepositives/" ],
"url" : "https://true-positives.com"
}
```
```json
{
"@context" : "https://schema.org",
"@type" : "Product",
"aggregateRating" : {
"@type" : "AggregateRating",
"ratingValue" : "5",
"reviewCount" : "3"
},
"name" : "True Positives Managed AppSec Services",
"review" : [ {
"@type" : "Review",
"author" : {
"@type" : "Person",
"name" : "Brook Schoenfield"
},
"name" : "Valuable Insights for Strategic AppSec",
"reviewBody" : "True Positives goes beyond simply identifying vulnerabilities in application security testing. Their managed service delivers actionable insights and prioritization, allowing businesses to mitigate risks effectively and allocate resources strategically, all while controlling costs.",
"reviewRating" : {
"@type" : "Rating",
"bestRating" : "5",
"ratingValue" : "5"
}
}, {
"@type" : "Review",
"author" : {
"@type" : "Person",
"name" : "Dan Kuykendall"
},
"name" : "Reliable Scanning with Human Guidance",
"reviewBody" : "True Positives offers a great option for managed scanning, offering a cost-effective solution for quality and reliable scans. They don’t just send reports—they verify vulnerabilities, guide developers, and help prioritize and fix issues.",
"reviewRating" : {
"@type" : "Rating",
"bestRating" : "5",
"ratingValue" : "5"
}
}, {
"@type" : "Review",
"author" : {
"@type" : "Person",
"name" : "Julie Richard"
},
"name" : "Trusted DAST Partner for Enterprise Needs",
"reviewBody" : "Partnering with True Positives for managed DAST services will save you countless hours and headaches. Their expertise and proactive approach streamline identification and prioritization of vulnerabilities while also ensuring development has the information it needs to secure valuable assets.",
"reviewRating" : {
"@type" : "Rating",
"bestRating" : "5",
"ratingValue" : "5"
}
} ]
}
```