Application and API security (SIAS APP)

About this domain

Terms and testing rules used in this domain:

Confirmed exploitable: a technical tester has demonstrated the weakness with a safe proof (for example a harmless payload that shows script execution, a query that returns data it should not, or a request that reaches an address it should not), or has shown from code or configuration that exploitation needs no precondition an attacker could not meet. Automated results alone never establish or rule out a finding.
Test accounts: the applicant provides at least two test accounts for each role in scope and, for multi-tenant applications, accounts in at least two tenants. Testing uses synthetic data. Personal information encountered during testing is not copied beyond the minimum proof needed and is referenced in the evidence store by hash.
Test environment: testing runs against production or against an environment that SecurityInspect confirms runs the same code and security configuration as production, as agreed in the rules of engagement. Denial-of-service testing is never performed.
Vulnerability classes are identified by MITRE Common Weakness Enumeration (CWE) identifiers for precision. Testers may use public testing guides as informative references; the SIAS requirements are SecurityInspect's own.

Controls in this domain

5 controls, 3 of them mandatory.

Controls in the APP domain
Control	Title	Mandatory	Severity	Applies
SIAS-APP-01	Application security requirements and threat modeling	No	Medium	Conditional — in-scope web or mobile applications or APIs
SIAS-APP-02	Resistance to common web and API vulnerability classes	Yes	Critical	Conditional — in-scope web or mobile applications or APIs
SIAS-APP-03	Application authentication, session management and authorization	Yes	Critical	Conditional — in-scope web or mobile applications or APIs
SIAS-APP-04	API inventory, protection and abuse controls	Yes	High	Conditional — in-scope APIs reachable by customers, partners or the internet
SIAS-APP-05	Browser security controls and third-party scripts	No	Medium	Conditional — in-scope websites or browser-delivered applications

SIAS-APP-01 Application security requirements and threat modeling

Mandatory: No
Severity: Medium
Applies: Conditional — in-scope web or mobile applications or APIs
SecurityInspect Verified profiles: VP-APP

Control objective

The security needs of each in-scope application are identified before and during development, so that design flaws are found and handled deliberately rather than discovered after release.

Testable requirement

1.For each in-scope application and API, the applicant shall document security requirements covering at least: authentication and session handling; the authorization model (roles and, where relevant, tenancy); the classification of data processed (SIAS-DAT-01); input handling; security event logging; third-party components and integrations; and secrets handling.
2.The applicant shall maintain a threat model for each in-scope application that identifies its components, trust boundaries, data flows, entry points, likely threats and planned mitigations.
3.The threat model shall be reviewed at least every 12 months, and before release of any change that adds an external interface, a new Confidential or Restricted data type, a new trust boundary or a new authentication method.
4.Mitigations identified in the threat model shall be tracked as work items with owners until they are implemented or accepted under SIAS-RSK-02.

Applicability and scope

Conditional — in-scope web or mobile applications or APIs. Marking it not applicable needs a quality-reviewer-approved rationale showing that the scope contains none. For commercial software or SaaS that the applicant only configures, testable requirement 1 applies to its configuration and integrations, and the threat model covers the integration. SecurityInspect Verified profiles: VP-APP.

Pass criteria

1.Security requirements covering every topic in testable requirement 1 exist for every in-scope application (M1).
2.A threat model containing every element in testable requirement 2 exists for every in-scope application (M2).
3.Each threat model was reviewed within the 12 months before fieldwork, and every sampled triggering change was preceded by an update (M3, A2).
4.A1 finds no undocumented external entry point that handles authentication or Confidential or Restricted data.
5.Every sampled mitigation is implemented or accepted (M4).

Severity

Medium. No escalation trigger.

Informative framework mappings

HIPAA Security Rule: No direct mapping
PCI DSS v4.0.1: 6.2
Trust Services Criteria: CC8.1
ISO/IEC 27001:2022: A.8.26, A.8.27
Theme (SecurityInspect wording): security needs defined, threats modeled early

SIAS-APP-02 Resistance to common web and API vulnerability classes

Mandatory: Yes
Severity: Critical
Applies: Conditional — in-scope web or mobile applications or APIs
SecurityInspect Verified profiles: VP-APP

Control objective

In-scope applications and APIs contain no exploitable weakness of the classes most often used to steal data or take control of systems.

Testable requirement

1.In-scope applications and APIs shall contain no confirmed exploitable vulnerability of these classes:
- SQL, NoSQL, LDAP and operating-system command injection (CWE-89, CWE-943, CWE-90, CWE-78);
- code and server-side template injection (CWE-94, CWE-1336);
- cross-site scripting, including stored and DOM-based (CWE-79);
- server-side request forgery (CWE-918);
- XML external entity processing (CWE-611);
- deserialization of untrusted data (CWE-502);
- path traversal and file inclusion (CWE-22, CWE-98);
- unrestricted file upload (CWE-434);
- cross-site request forgery on state-changing functions (CWE-352);
- open redirects usable in authentication flows (CWE-601);
- exposure of sensitive information through error messages, active debug code or published source (CWE-209, CWE-489, CWE-540).
2.Each in-scope application shall use these design defenses: parameterized queries or safe query interfaces for data access; context-aware output encoding, or a templating framework that encodes by default; server-side validation of input type, length and format; an allow-list for outbound requests made on a user's behalf; external entity resolution disabled in XML parsers; anti-forgery protection (tokens, or SameSite cookies with origin checks) for state-changing requests; and production error handling that does not reveal stack traces, queries or internal paths.
3.Debug modes, framework administration consoles and development endpoints shall not be reachable from the internet in production.
4.Known exploitable vulnerabilities in application dependencies that are reachable from application code shall be remediated within the SIAS-VPM-02 timeframes (software composition is governed by SIAS-SDC-05).

Applicability and scope

Conditional — in-scope web or mobile applications or APIs. For mobile applications, the back-end APIs are tested and the application package is analyzed where the applicant supplies it. Every in-scope application must be tested; an application that is not tested blocks gate G1. SecurityInspect Verified profiles: VP-APP.

Pass criteria

1.Every in-scope application and API was tested for every class in testable requirement 1, and coverage is recorded (M5).
2.No confirmed exploitable vulnerability of a class in testable requirement 1 remains after retest (A2, M1, M2).
3.No debug mode, framework console or development endpoint is reachable from the internet in production (A3, M1).
4.No reachable dependency vulnerability that is KEV-listed or rated Critical remains beyond its SIAS-VPM-02 timeframe (A4, M1).
5.Where source access is in scope, every sampled code path uses the design defenses in testable requirement 2 or an alternative the tester confirms prevents the class (M3). A missing defense without an exploitable result is recorded as a finding against SIAS-APP-01 or SIAS-SDC-02 at that control's severity, or as an Observation, and does not by itself fail this criterion.

Severity

Critical. A confirmed exploitable vulnerability of a class in testable requirement 1 is rated by its impact: Critical when it permits code execution, unauthenticated access to data, account takeover or access to internal systems, or when a mandatory escalation trigger applies (§5.7); High for any other confirmed injection, cross-site scripting, server-side request forgery, XML external entity, deserialization, path traversal, file upload or cross-site request forgery weakness; Medium for information exposure through error messages, active debug code or published source, and for an open redirect, when no chained impact is shown. Rating a finding below these levels needs written rationale, quality-reviewer concurrence and, when lowering from Critical, the second independent reviewer's agreement. Any finding leaves this mandatory control not Met, so it must be remediated and retested before any SecurityInspect Certified or SecurityInspect Verified decision.

Informative framework mappings

HIPAA Security Rule: No direct mapping
PCI DSS v4.0.1: 6.2, 6.4
Trust Services Criteria: CC6.6
ISO/IEC 27001:2022: A.8.26, A.8.28
Theme (SecurityInspect wording): applications resist common attack classes

SIAS-APP-03 Application authentication, session management and authorization

Mandatory: Yes
Severity: Critical
Applies: Conditional — in-scope web or mobile applications or APIs
SecurityInspect Verified profiles: VP-APP

Control objective

Only the right people and systems can sign in to in-scope applications, sessions cannot be hijacked or reused, and every request is limited to what the caller's role and tenancy allow.

Testable requirement

Authentication
- 1.Applications shall authenticate every user and API client before giving access to non-public functions or data, and shall enforce this on the server.
- 2.Administrative and privileged application functions, and support or back-office tools that can view or change customer data, shall require multi-factor authentication (consistent with SIAS-IAM-02), either directly or through single sign-on to an identity provider that enforces it. Applications that store Restricted data should offer multi-factor authentication to end users.
- 3.Where an application stores passwords, it shall store them only as salted hashes produced by an adaptive or memory-hard function (for example Argon2id, scrypt, bcrypt or PBKDF2) with a work factor set in the applicant's documented standard and reviewed at least every 12 months; shall reject passwords known to be compromised or on a common-password list; and shall require at least 8 characters where a second factor is also required, and at least 12 characters where the password is the only factor.
- 4.Applications shall limit repeated failed sign-in, second-factor and reset attempts per account and per source (by throttling, progressive delay, lockout or challenge). Sign-in and password-reset responses shall not reveal whether an account exists.
- 5.Password reset and account recovery shall use single-use random tokens of at least 128 bits that expire within 60 minutes, sent only to a channel verified in advance. A completed reset shall end the account's other active sessions.
Session management
- 6.Session identifiers shall come from a cryptographically secure random generator with at least 128 bits of entropy, shall be issued anew at sign-in and at any privilege change, shall be invalidated on the server at sign-out, and shall be sent only over TLS.
- 7.Session cookies shall carry the Secure and HttpOnly attributes and a SameSite attribute of Lax or Strict (CWE-614, CWE-1004, CWE-1275). SameSite=None is permitted only for a documented cross-site need, with anti-forgery protection under SIAS-APP-02.
- 8.Sessions shall have documented idle and absolute timeouts based on risk. Limits: for privileged or administrative sessions, no more than 30 minutes idle and 12 hours absolute; for sessions in applications that store Restricted data, no more than 60 minutes idle and 24 hours absolute without re-authentication. API access tokens shall expire within 60 minutes, and refresh tokens shall be rotated on use and revocable.
Authorization
- 9.Authorization shall be enforced on the server for every request, at both the function level (role) and the object level (each record or resource), denying by default (CWE-862, CWE-863, CWE-639).
- 10.Multi-tenant applications shall keep tenants apart so that no user or API client can read or change another tenant's data by altering identifiers, parameters, tokens or headers.
- 11.Changes to roles and permissions within the application shall be limited to authorized administrators and logged (SIAS-LOG-01).

Applicability and scope

Conditional — in-scope web or mobile applications or APIs. Testable requirements 3 to 5 apply only where the application manages its own credentials. Where authentication is fully delegated to an external identity provider, that provider's configuration for the application is tested for the same outcomes (MFA enforcement, throttling, recovery and session lifetime). SecurityInspect Verified profiles: VP-APP.

Pass criteria

1.No confirmed authentication bypass, session fixation or hijacking path, or missing server-side authentication on a non-public function (A1, A2, M1).
2.Multi-factor authentication is enforced on every administrative, privileged and support function, with no alternative path that skips it (M4).
3.Where passwords are stored: salted adaptive or memory-hard hashing, compromised-password screening and the length rules are all in place (M5).
4.Throttling works on sign-in, second-factor and reset endpoints, and sign-in and reset responses do not reveal whether an account exists (A1).
5.Reset tokens are single-use, at least 128 bits, expire within 60 minutes, and a completed reset ends other sessions (A1, M6).
6.Session identifiers meet testable requirement 6 and session cookies meet testable requirement 7 (A2).
7.Measured timeouts are within the documented values and within the limits for privileged and Restricted-data sessions (A3).
8.The authorization matrix and tenant-isolation tests show no unauthorized read, change, delete or export (A4, M2, M3).
9.Self-contained tokens are signature-checked, and unsigned or algorithm-switched tokens are rejected (A5).

Severity

Critical. A confirmed authentication bypass, a session fixation or hijacking path, or broken object-level or tenant authorization that exposes or changes other users' data is Critical. Authentication bypass on an internet-facing system is a mandatory escalation trigger (§5.7) and cannot be lowered. A weakness that does not directly expose data or accounts (for example an absolute timeout longer than documented, or a missing cookie attribute) may be lowered one level with written rationale, quality-reviewer concurrence and the second independent reviewer's agreement; the control is still Not met until remediated and retested.

Informative framework mappings

HIPAA Security Rule: §164.312(a)(1), §164.312(a)(2)(iii), §164.312(d)
PCI DSS v4.0.1: 6.2, 8.3
Trust Services Criteria: CC6.1
ISO/IEC 27001:2022: A.8.3, A.8.5
Theme (SecurityInspect wording): strong sign-in, sessions and per-request authorization

SIAS-APP-04 API inventory, protection and abuse controls

Mandatory: Yes
Severity: High
Applies: Conditional — in-scope APIs reachable by customers, partners or the internet
SecurityInspect Verified profiles: VP-APP

Control objective

The applicant knows every API it exposes, and each one authenticates its callers, accepts only valid input, returns only the data the caller needs and resists automated abuse.

Testable requirement

1.The applicant shall keep an inventory of every in-scope API reachable by customers, partners or the internet, recording base URLs, versions, owner, authentication method, classification of data handled, and a machine-readable or written specification of its endpoints (for example an OpenAPI description). Deprecated versions that are still reachable shall be listed with a retirement date.
2.Every non-public endpoint shall require authentication. API keys, client credentials and tokens shall be scoped to least privilege, attributable to one customer, partner or workload, revocable, and never accepted in URL query strings.
3.APIs shall validate request bodies and parameters against their specification on the server, shall reject unexpected fields rather than bind them to internal objects (CWE-915), and shall return only the fields documented for the caller's role.
4.APIs shall enforce rate limits or quotas per client and per source on authentication, enumeration-prone (search, lookup and list) and resource-intensive endpoints, and shall limit request size and page size (CWE-770).
5.Endpoints that trigger sensitive business actions (for example payments, account changes, messaging or bulk exports) shall have controls against automated misuse that match the documented risk (for example per-account limits, step-up authentication or anomaly alerts).
6.API requests and errors shall be logged with the client identity (SIAS-LOG-01). Where the applicant sends webhooks it shall sign them; where it receives webhooks it shall check their signatures.

Applicability and scope

Conditional — in-scope APIs reachable by customers, partners or the internet. Covers REST, GraphQL, RPC-style and SOAP interfaces. Internal-only APIs are covered by SIAS-APP-02 and SIAS-APP-03. SecurityInspect Verified profiles: VP-APP.

Pass criteria

1.The inventory contains the required fields, and every endpoint found by A1 is in it, or has been retired and confirmed unreachable at retest (M2).
2.A2 finds no non-public endpoint that returns data or performs an action without valid, correctly scoped credentials.
3.A3 and A4 find no binding of unexpected fields and no undocumented sensitive fields in responses. GraphQL introspection is disabled in production or limited to authenticated developers, and depth and batching limits are in place.
4.Rate limits are in place on authentication, enumeration-prone and resource-intensive endpoints (A5).
5.No credential is accepted in a URL query string (A6).
6.The test key stops working within the documented time (M5), and webhook signing or signature checking is in place wherever webhooks are used.
7.API requests are logged with client identity (E5).

Severity

High. Mandatory escalation to Critical (§5.7): authentication bypass on an internet-facing API; Restricted or sensitive data or credentials returned to unauthenticated callers. Broken object-level authorization that exposes other customers' data is recorded as a Critical finding under SIAS-APP-03.

Informative framework mappings

HIPAA Security Rule: No direct mapping
PCI DSS v4.0.1: 6.2, 6.4
Trust Services Criteria: CC6.6
ISO/IEC 27001:2022: A.8.26
Theme (SecurityInspect wording): known, authenticated, validated, rate-limited APIs

SIAS-APP-05 Browser security controls and third-party scripts

Mandatory: No
Severity: Medium
Applies: Conditional — in-scope websites or browser-delivered applications
SecurityInspect Verified profiles: VP-EXT, VP-APP

Control objective

In-scope websites tell browsers to block common client-side attacks, and every script that runs on their pages is known, authorized and watched for unexpected change.

Testable requirement

1.In-scope websites shall send a Content-Security-Policy that restricts script sources to an explicit list or uses nonces or hashes. On pages that handle sign-in, payment, or Confidential or Restricted data, the policy shall not allow 'unsafe-inline' or 'unsafe-eval' for scripts. Other pages should meet the same policy.
2.In-scope websites shall prevent framing by other origins (CSP frame-ancestors or X-Frame-Options; CWE-1021) unless framing is a documented feature limited to named origins; shall send X-Content-Type-Options: nosniff; and shall set a Referrer-Policy that does not send full URLs to other origins (for example strict-origin-when-cross-origin or stricter).
3.The applicant shall keep an inventory of the third-party scripts, tags and embedded frames loaded on in-scope pages, recording source, purpose, owner, business justification and the data each can reach, and shall authorize each one before it is added (CWE-829).
4.Static third-party scripts loaded from other origins should use Subresource Integrity. A script that cannot use it (for example because it changes by design) shall be marked as such in the inventory with the reason.
5.For pages that collect credentials, payment data, or Confidential or Restricted data, the applicant shall detect unauthorized changes to scripts and security headers at least weekly and alert a named owner.

Applicability and scope

Conditional — in-scope websites or browser-delivered applications. SecurityInspect Verified profiles: VP-EXT (the declared internet-facing websites); VP-APP (the named application's browser front end).

Pass criteria

1.Every sensitive page sends a Content-Security-Policy meeting testable requirement 1 (A1, M5).
2.Every in-scope page type has framing protection, nosniff and a conforming Referrer-Policy (A1, A5).
3.Every third-party script and domain observed on in-scope pages is in the inventory with the required fields and an authorization record (A3, M2, M3).
4.Every third-party script without Subresource Integrity is marked with a reason.
5.Change detection covers every sensitive page at least weekly, with alerts reaching a named owner, shown by alert history or a test alert (M4).

Severity

Medium. Mandatory escalation to Critical (§5.7): a malicious or tampered script observed on an in-scope page (active compromise); or a script that sends credentials or Restricted data to a destination outside the applicant's control that is not a disclosed, contracted recipient, which SIAS treats as exposure of sensitive data or credentials to unauthenticated parties.

Informative framework mappings

HIPAA Security Rule: No direct mapping
PCI DSS v4.0.1: 6.4, 11.6
Trust Services Criteria: CC6.8
ISO/IEC 27001:2022: A.8.26
Theme (SecurityInspect wording): browser defenses and controlled page scripts

Framework mappings in this domain

The mappings above are informative cross-references by identifier only. They don’t reproduce any framework’s text, and meeting a SIAS control doesn’t mean any framework requirement is met.

What framework mappings mean

SecurityInspect certification is a proprietary, scope-limited assessment against the SecurityInspect Assurance Standard. Framework mappings indicate thematic alignment only. Certification does not constitute an HHS-recognized HIPAA certification, PCI DSS validation, a SOC 2 examination or report, or accredited ISO/IEC 27001 certification.

How SIAS relates to other security frameworks

Where our work stops

Security Inspect is not a law firm or a CPA firm and does not provide legal opinions or issue SOC 2 reports. ISO/IEC 27001 certification is performed independently by an accredited certification body. CMMC organization-level assessment authority depends on an active C3PAO listing. Specific PCI services depend on the company’s active PCI SSC program listing and scope.

Talk to us about a SIAS assessment

Tell us what you want assessed, and we’ll start with the scope.

Apply for SIAS certification Verify a certificate