M1013: Application Developer Guidance
Application Developer Guidance focuses on providing developers with the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles. By integrating security throughout the software development lifecycle (SDLC), this mitigation aims to prevent the introduction of exploitable weaknesses in applications, systems, and APIs. This mitigation can be implemented through the following measures: Preventing SQL Injection (Secure Coding Practice):
- Implementation: Train developers to use parameterized queries or prepared statements instead of directly embedding user input into SQL queries. - Use Case: A web application accepts user input to search a database. By sanitizing and validating user inputs, developers can prevent attackers from injecting malicious SQL commands.
Cross-Site Scripting (XSS) Mitigation:
- Implementation: Require developers to implement output encoding for all user-generated content displayed on a web page. - Use Case: An e-commerce site allows users to leave product reviews. Properly encoding and escaping user inputs prevents malicious scripts from being executed in other users’ browsers.
Secure API Design:
- Implementation: Train developers to authenticate all API endpoints and avoid exposing sensitive information in API responses. - Use Case: A mobile banking application uses APIs for account management. By enforcing token-based authentication for every API call, developers reduce the risk of unauthorized access.
Static Code Analysis in the Build Pipeline:
- Implementation: Incorporate tools into CI/CD pipelines to automatically scan for vulnerabilities during the build process. - Use Case: A fintech company integrates static analysis tools to detect hardcoded credentials in their source code before deployment.
Threat Modeling in the Design Phase:
- Implementation: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to assess threats during application design. - Use Case: Before launching a customer portal, a SaaS company identifies potential abuse cases, such as session hijacking, and designs mitigations like secure session management.
**Tools for Implementation**:
- Static Code Analysis Tools: Use tools that can scan for known vulnerabilities in source code. - Dynamic Application Security Testing (DAST): Use tools like Burp Suite or OWASP ZAP to simulate runtime attacks and identify vulnerabilities. - Secure Frameworks: Recommend secure-by-default frameworks (e.g., Django for Python, Spring Security for Java) that enforce security best practices.
Security context for executives and security teams
Application Developer Guidance is a prevention-focused mitigation: it reduces business risk by helping teams avoid shipping exploitable weaknesses in applications, APIs, mobile apps, and software delivery paths. Its value is not a single control, but disciplined SDLC evidence: secure coding practices, threat modeling, API authentication, input/output handling, and automated security testing before release.
Executive priority
Treat this as a resilience and risk-reduction investment for software-dependent business processes. Leaders should ask whether security requirements are built into design, development, CI/CD, and release approval—not added only after incidents or audits. The relationship context connects this mitigation to risks involving valid accounts, application access tokens, credential access, supply chain compromise, SaaS impact such as SMS pumping, and platform-specific abuse patterns. That makes it relevant to identity readiness, cloud/API governance, vulnerability prevention, and compliance evidence for secure development practices.
Technical view
SOC, detection engineering, AppSec, and IR teams should validate that development controls map to the related ATT&CK behaviors: credential and token misuse, software dependency or development-tool compromise, insecure APIs, exposed code repositories, and application design weaknesses that enable execution, stealth, or privilege-related abuse. Because MITRE provides no detection text for this mitigation, coverage should be assessed through SDLC control evidence and runtime telemetry around applications and APIs rather than assuming an ATT&CK detection analytic exists.
Likely telemetry
- Secure coding training completion and developer guidance records
- Threat modeling outputs and design review evidence
- Code review records for authentication, authorization, input validation, output encoding, and session/token handling
- Static code analysis results from build pipelines
- Dynamic application security testing results
Detection direction
- Do not treat this mitigation as a SOC alert by itself; MITRE provides no official detection guidance for M1013.
- Validate whether application and API logs can support investigation of related behaviors such as valid account abuse, application access token misuse, unauthorized API access, and suspicious use of exposed services.
- Tune AppSec findings so teams can distinguish exploitable coding weaknesses from informational issues, especially for SQL injection, XSS, hardcoded credentials, unauthenticated APIs, and insecure dependency use described in the official mitigation text.
- Use relationship context to prioritize testing and monitoring for applications tied to identity providers, SaaS, containers, IaaS, mobile apps, and code repositories where applicable.
- Watch for blind spots where build-time scanning exists but does not cover design flaws, API authorization logic, mobile URI handling, dependency trust, or runtime token behavior.
Mitigation priorities
- Start with secure SDLC expectations: documented developer guidance, secure design principles, and threat modeling before implementation.
- Require secure coding practices for common weakness classes cited by MITRE, including parameterized queries, input validation, output encoding, and authenticated API endpoints.
- Integrate static analysis and dynamic application security testing into CI/CD so issues are found before deployment.
- Add dependency and development-tool review to reduce supply chain compromise risk, including scrutiny of open-source components and build pipeline inputs.
- Validate authentication, authorization, token handling, and sensitive-data exposure controls for APIs and mobile/cloud-connected applications.
Additional notes and limits
This object is a mitigation, not an adversary behavior. Its practical value is strongest when AppSec, IAM, cloud, SOC, and IR teams use it as a control framework for reducing weaknesses that enable the related ATT&CK techniques. The supplied relationships broaden the relevance beyond web applications to identity providers, SaaS, IaaS, containers, mobile platforms, code repositories, and software supply chain paths, but local system scope must be confirmed.
The official object does not specify platforms, tactics, or detection guidance for M1013 itself. The related techniques provide context, but they do not prove exposure, exploitation, or detection coverage in any specific environment. Implementation quality depends on local SDLC maturity, application architecture, logging, testing depth, and developer adoption.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Application Developer Guidance
Application Developer Guidance focuses on providing developers with the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles. By integrating security throughout the software development lifecycle (SDLC), this mitigation aims to prevent the introduction of exploitable weaknesses in applications, systems, and APIs. This mitigation can be implemented through the following measures: Preventing SQL Injection (Secure Coding Practice):
- Implementation: Train developers to use parameterized queries or prepared statements instead of directly embedding user input into SQL queries. - Use Case: A web application accepts user input to search a database. By sanitizing and validating user inputs, developers can prevent attackers from injecting malicious SQL commands.
Cross-Site Scripting (XSS) Mitigation:
- Implementation: Require developers to implement output encoding for all user-generated content displayed on a web page. - Use Case: An e-commerce site allows users to leave product reviews. Properly encoding and escaping user inputs prevents malicious scripts from being executed in other users’ browsers.
Secure API Design:
- Implementation: Train developers to authenticate all API endpoints and avoid exposing sensitive information in API responses. - Use Case: A mobile banking application uses APIs for account management. By enforcing token-based authentication for every API call, developers reduce the risk of unauthorized access.
Static Code Analysis in the Build Pipeline:
- Implementation: Incorporate tools into CI/CD pipelines to automatically scan for vulnerabilities during the build process. - Use Case: A fintech company integrates static analysis tools to detect hardcoded credentials in their source code before deployment.
Threat Modeling in the Design Phase:
- Implementation: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to assess threats during application design. - Use Case: Before launching a customer portal, a SaaS company identifies potential abuse cases, such as session hijacking, and designs mitigations like secure session management.
**Tools for Implementation**:
- Static Code Analysis Tools: Use tools that can scan for known vulnerabilities in source code. - Dynamic Application Security Testing (DAST): Use tools like Burp Suite or OWASP ZAP to simulate runtime attacks and identify vulnerabilities. - Secure Frameworks: Recommend secure-by-default frameworks (e.g., Django for Python, Spring Security for Java) that enforce security best practices.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1496.003 | SMS PumpingSub-technique | Consider implementing CAPTCHA protection on forms that send messages via SMS. |
| Enterprise | T1647 | Plist File Modification | Ensure applications are using Apple's developer guidance which enables hardened runtime.[1] |
| Enterprise | T1195 | Supply Chain Compromise | Application developers should be cautious when selecting third-party libraries to integrate into their application. Additionally, where possible, developers should lock software dependencies to specific versions rather than pulling the latest version on build.[2] |
| Enterprise | T1574 | Hijack Execution Flow | When possible, include hash values in manifest files to help prevent side-loading of malicious libraries.[3] |
| Enterprise | T1564 | Hide Artifacts | Application developers should consider limiting the requirements for custom or otherwise difficult to manage file/folder exclusions. Where possible, install applications to trusted system folder paths that are already protected by restricted file and directory permissions. |
| Enterprise | T1212 | Exploitation for Credential Access | |
| Enterprise | T1564.012 | File/Path ExclusionsSub-technique | Application developers should consider limiting the requirements for custom or otherwise difficult to manage file/folder exclusions. Where possible, install applications to trusted system folder paths that are already protected by restricted file and directory permissions. |
| Enterprise | T1550.001 | Application Access TokenSub-technique | |
| Enterprise | T1559.003 | XPC ServicesSub-technique | Enable the Hardened Runtime capability when developing applications. Do not include the |
| Enterprise | T1550 | Use Alternate Authentication Material | |
| Enterprise | T1593.003 | Code RepositoriesSub-technique | Application developers uploading to public code repositories should be careful to avoid publishing sensitive information such as credentials and API keys. |
| Enterprise | T1078 | Valid Accounts | Ensure that applications do not store sensitive data or credentials insecurely. (e.g. plaintext credentials in code, published credentials in repositories, or credentials in public cloud storage). |
| Enterprise | T1564.009 | Resource ForkingSub-technique | Configure applications to use the application bundle structure which leverages the |
| Enterprise | T1574.001 | DLLSub-technique | When possible, include hash values in manifest files to help prevent side-loading of malicious libraries. |
| Enterprise | T1195.001 | Compromise Software Dependencies and Development ToolsSub-technique | Application developers should be cautious when selecting third-party libraries to integrate into their application. Additionally, where possible, developers should lock software dependencies to specific versions rather than pulling the latest version on build.[2] GitHub Actions may be pinned to a specific commit hash rather than a tag or branch.[9] |
| Enterprise | T1593 | Search Open Websites/Domains | Application developers uploading to public code repositories should be careful to avoid publishing sensitive information such as credentials and API keys. |
| Enterprise | T1559 | Inter-Process Communication | Enable the Hardened Runtime capability when developing applications. Do not include the |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Imported snapshots across ATT&CK releases(1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | 43fd9730d046… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
- [1]Apple Developer Doco Hardened Runtime
Apple Inc.. (2021, January 1). Hardened Runtime: Manage security protections and resource access for your macOS apps.. Retrieved March 24, 2021.
Open source URL - [2]Cider Security Top 10 CICD Security Risks
Daniel Krivelevich and Omer Gil. (n.d.). Top 10 CI/CD Security Risks. Retrieved November 17, 2024.
Open source URL - [3]FireEye DLL Side-Loading
Amanda Steward. (2014). FireEye DLL Side-Loading: A Thorn in the Side of the Anti-Virus Industry. Retrieved March 13, 2020.
Open source URL - [4]Comparitech Replay Attack
Justin Schamotta. (2022, October 28). What is a replay attack?. Retrieved September 27, 2023.
Open source URL - [5]Bugcrowd Replay Attack
Bugcrowd. (n.d.). Replay Attack. Retrieved September 27, 2023.
Open source URL - [6]Microsoft Token Protection 2023
Microsoft. (2023, October 23). Conditional Access: Token protection (preview). Retrieved January 2, 2024.
Open source URL - [7]Okta DPoP 2023
Venkat Viswanathan. (2023, June 13). A leap forward in token security: Okta adds support for DPoP. Retrieved January 2, 2024.
Open source URL - [8]Apple App Security Overview
Apple Inc. (2021, February 18). App security overview. Retrieved October 12, 2021.
Open source URL - [9]Unit 42 Palo Alto GitHub Actions Supply Chain Attack 2025
Omer Gilm Aviad Hahami, Asi Greenholts, and Yaron Avital. (2025, March 20). GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj-actions/changed-files Incident: Threat Assessment . Retrieved May 22, 2025.
Open source URL - [10]mitre-attackM1013Open source URL
- [11]mitre-attackM1013Open source URL
- [12]mitre-attackM1013Open source URL
- [13]Apple Developer Doco Hardened Runtime
Apple Inc.. (2021, January 1). Hardened Runtime: Manage security protections and resource access for your macOS apps.. Retrieved March 24, 2021.
Open source URL - [14]Cider Security Top 10 CICD Security Risks
Daniel Krivelevich and Omer Gil. (n.d.). Top 10 CI/CD Security Risks. Retrieved November 17, 2024.
Open source URL - [15]FireEye DLL Side-Loading
Amanda Steward. (2014). FireEye DLL Side-Loading: A Thorn in the Side of the Anti-Virus Industry. Retrieved March 13, 2020.
Open source URL - [16]Bugcrowd Replay Attack
Bugcrowd. (n.d.). Replay Attack. Retrieved September 27, 2023.
Open source URL - [17]Comparitech Replay Attack
Justin Schamotta. (2022, October 28). What is a replay attack?. Retrieved September 27, 2023.
Open source URL - [18]Microsoft Token Protection 2023
Microsoft. (2023, October 23). Conditional Access: Token protection (preview). Retrieved January 2, 2024.
Open source URL - [19]Okta DPoP 2023
Venkat Viswanathan. (2023, June 13). A leap forward in token security: Okta adds support for DPoP. Retrieved January 2, 2024.
Open source URL - [20]Microsoft Token Protection 2023
Microsoft. (2023, October 23). Conditional Access: Token protection (preview). Retrieved January 2, 2024.
Open source URL - [21]Microsoft Token Protection 2023
Microsoft. (2023, October 23). Conditional Access: Token protection (preview). Retrieved January 2, 2024.
Open source URL - [22]Okta DPoP 2023
Venkat Viswanathan. (2023, June 13). A leap forward in token security: Okta adds support for DPoP. Retrieved January 2, 2024.
Open source URL - [23]Okta DPoP 2023
Venkat Viswanathan. (2023, June 13). A leap forward in token security: Okta adds support for DPoP. Retrieved January 2, 2024.
Open source URL - [24]Apple App Security Overview
Apple Inc. (2021, February 18). App security overview. Retrieved October 12, 2021.
Open source URL - [25]Cider Security Top 10 CICD Security Risks
Daniel Krivelevich and Omer Gil. (n.d.). Top 10 CI/CD Security Risks. Retrieved November 17, 2024.
Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.