Web, API, Database and Secure Software Assessment

Introduction and Context

Modern organisations deliver services through browser applications, mobile applications, public and internal APIs, databases, cloud platforms, and software supply chains. These components form an interdependent application ecosystem. A weakness in an API may expose a database; an insecure dependency may compromise an otherwise well-designed service; and a business-logic defect may permit fraud without producing a conventional injection alert.

Application security assessment therefore extends beyond vulnerability scanning. It combines threat modelling, source and architecture review, controlled testing, evidence analysis, risk evaluation, and remediation validation. The assessor must understand not only whether a technical defect exists, but also what business process it affects, which identities and assets are exposed, how reliably it can be exploited, and which controls reduce the risk.

This chapter applies the principles of the OWASP Top 10, OWASP API Security Top 10, OWASP Web Security Testing Guide, OWASP Application Security Verification Standard (ASVS), OWASP Software Assurance Maturity Model (SAMM), and OWASP Software Component Verification Standard (SCVS). These are guidance frameworks rather than substitutes for organisational policy, sector regulation, or professional judgement.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Plan an ethical assessment of web applications, APIs, databases, and software delivery pipelines.
2. Explain and test input handling, authentication, session management, access control, and business logic.
3. Distinguish common web and API weaknesses and select suitable evidence.
4. Assess database exposure, data protection, and injection risk without causing unnecessary harm.
5. Evaluate dependency, build-pipeline, container, and configuration risks.
6. Relate findings to threat models, business impact, secure design, and remediation priorities.
7. Recommend DevSecOps controls and communicate results responsibly.

1. Scope, Rules of Engagement and Assessment Models

A professional assessment begins with authorisation. The rules of engagement should identify in-scope domains, applications, API versions, test accounts, permitted techniques, testing hours, rate limits, prohibited actions, data-handling requirements, emergency contacts, and reporting expectations. Production testing requires particular care: destructive actions, denial-of-service activity, mass enumeration, real payment transactions, and extraction of personal data should normally be prohibited unless explicitly approved and safely controlled.

A useful assessment combines several perspectives:

The assessment should map each test to an objective. For example, a test of object-level authorisation asks whether user A can retrieve user B’s invoice by changing an object identifier. It should not be described merely as “testing the API.” Evidence should include the request, the identity and permissions used, the expected result, the observed result, and the safe impact statement.

Risk-based prioritisation

Technical severity and business risk are related but not identical. A low-complexity vulnerability affecting a public payment endpoint may deserve higher priority than a more technically complex defect in an isolated administrative tool. A practical qualitative model considers:

• Asset value: confidentiality, integrity, availability, financial or safety importance.
• Exposure: internet accessibility, partner access, internal-only access, or isolated deployment.
• Exploitability: required privileges, user interaction, complexity, and reliability.
• Impact: data disclosure, fraud, account takeover, service disruption, or regulatory consequences.
• Control environment: monitoring, segmentation, rate limiting, backups, and response capability.

CVSS can provide a standardised technical severity score, but it does not replace business-context analysis. Findings should state both the technical rating and the organisational consequence.

2. Threat Modelling for Applications and APIs

Threat modelling is a structured way to anticipate abuse before or during testing. The assessor identifies assets, actors, entry points, trust boundaries, data flows, and security assumptions. STRIDE is a useful starting model: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. For application abuse, business-process modelling and attack trees are also important.

A data-flow diagram should show clients, identity providers, API gateways, services, queues, databases, third-party services, and administrative paths. Each arrow should be labelled with the data and authentication context it carries. The key question is not simply whether traffic is encrypted, but whether the receiving component validates the identity, authority, freshness, integrity, and intended purpose of the message.

For example, an API may correctly validate a JSON schema but still fail to verify that the authenticated customer owns the referenced account. Input validity and authorisation are separate security properties.

3. Input Handling and Injection Resistance

Input handling comprises validation, canonicalisation, encoding, parsing, and safe use of data. These operations must be designed according to context. A string that is safe in JSON may be dangerous when inserted into SQL, HTML, a shell command, an LDAP filter, a template, or a log record.

Validation principles

A robust validation strategy generally includes:

1. Canonicalise carefully: convert input to a well-defined representation before validation, while avoiding double-decoding and ambiguous encodings.
2. Use allowlists where practical: define permitted formats, ranges, lengths, enumerations, and character sets.
3. Validate type and structure: enforce JSON schemas, required fields, nesting limits, array sizes, and content types.
4. Reject ambiguity: treat duplicate parameters, conflicting headers, invalid Unicode, and unexpected methods consistently.
5. Apply context-specific output encoding: HTML, JavaScript, URL, SQL, and shell contexts require different protections.
6. Use safe APIs: parameterised queries, prepared statements, safe templating, and libraries that separate data from commands.

Validation is not a substitute for authorisation. Nor is escaping a universal defence. For SQL, parameterisation is the primary control; for HTML, context-aware output encoding and safe templating are central; for operating-system commands, avoiding command construction and using direct process APIs is preferable.

Common injection classes

SQL injection occurs when untrusted input changes the structure of a database query. NoSQL, LDAP, XPath, server-side template, expression-language, and command injection follow the same general pattern: data is interpreted as instructions. Tests should be non-destructive and should confirm behaviour using controlled markers rather than extracting unnecessary records.

Cross-site scripting (XSS) occurs when attacker-controlled content is executed in a victim’s browser. Stored XSS persists in an application; reflected XSS is returned in a response; DOM-based XSS arises through client-side processing. Content Security Policy can reduce impact but should not be treated as the primary fix for unsafe output handling.

Server-side request forgery (SSRF) occurs when a server makes a request influenced by an attacker. Risk may include access to internal services, cloud metadata, or administrative interfaces. Defences include strict destination allowlists, network egress restrictions, protection against DNS rebinding, redirect controls, and isolation of metadata services. Blocking a few textual forms of localhost is insufficient because address representations and resolution behaviour vary.

File upload features require extension and content validation, size limits, malware scanning where appropriate, storage outside executable web paths, safe filenames, and separate download handling. Archive extraction must address path traversal and resource exhaustion.

4. Authentication, Sessions and Identity

Authentication establishes who a subject is; authorisation determines what that subject may do. Confusing these functions is a common source of serious defects.

Important authentication controls include secure password hashing with a current, approved password-hashing algorithm; phishing-resistant multifactor authentication for high-risk operations; account recovery that is no weaker than login; protection against credential stuffing; generic failure messages; and carefully designed lockout or throttling that does not enable denial of service against legitimate users.

Passwords should not be stored with reversible encryption or fast general-purpose hashes. Salts should be unique per password and managed by the password-hashing scheme. Secrets such as API keys, signing keys, and database credentials should be stored in an appropriately protected secrets-management system rather than source code or publicly accessible configuration.

Session security

A session identifier is a bearer credential. It should be unpredictable, transmitted only over protected channels, protected against client-side script access where possible, and scoped to the appropriate host and path. Cookie attributes should be selected deliberately:

• Secure: send the cookie only over HTTPS.
• HttpOnly: prevent ordinary JavaScript access.
• SameSite: reduce cross-site request risks, while considering legitimate cross-site flows.

Applications should rotate sessions after authentication and privilege changes, invalidate them on logout and risk events, enforce idle and absolute timeouts appropriate to the service, and avoid placing tokens in URLs. JWTs are signed claims, not automatically encrypted tokens or a replacement for revocation design. Validation must include signature, issuer, audience, expiry, algorithm policy, and appropriate key management.

CSRF protection is required when browsers automatically attach authentication credentials. Synchroniser tokens, carefully designed SameSite cookies, and origin checks may contribute to defence. A custom header alone is not sufficient unless the application ensures that cross-origin requests cannot set it under the relevant browser conditions.

5. Access Control and Business Logic

Access control failures frequently arise because developers protect user interfaces rather than server-side operations. Every sensitive action must enforce policy at the server, for every request and every object. A useful policy model evaluates:

Permit = f(subject, action, resource, context)

where subject is the authenticated identity, action is the requested operation, resource is the target object, and context includes tenant, time, device, transaction state, and other relevant conditions. The expression is conceptual rather than a universal algorithm; its purpose is to make policy inputs explicit.

Important classes include:

• Broken object-level authorisation: a user accesses another user’s record by changing an identifier.
• Broken function-level authorisation: a low-privilege identity invokes an administrative operation.
• Property-level authorisation failure: a client reads or modifies fields it should not control, such as account status or price.
• Tenant isolation failure: data or actions cross organisational boundaries.
• Privilege escalation: a subject gains capabilities outside the intended role or context.

Business-logic testing asks whether a legitimate sequence can be abused. Examples include applying a discount repeatedly, confirming an order without payment, cancelling after fulfilment, bypassing approval stages, replaying a one-time action, or submitting a negative quantity. These issues may not resemble conventional vulnerabilities and require domain knowledge, state modelling, and conversations with process owners.

Controls include server-side state transitions, transaction invariants, idempotency keys, replay detection, concurrency controls, independent price calculation, approval separation, and reconciliation with trusted systems. An idempotency key should be scoped to the authenticated actor and operation, have a defined lifetime, and produce a consistent result for safe retries; it must not become a mechanism for bypassing authorisation.

6. API Security Assessment

APIs expose machine-consumable contracts and often provide a larger attack surface than the visible web interface. Assessment should cover REST, GraphQL, SOAP, event-driven interfaces, webhooks, and internal service APIs where they are in scope.

API test areas

1. Inventory: identify versions, undocumented endpoints, HTTP methods, schemas, partner interfaces, and deprecated routes.
2. Transport and credentials: assess TLS, token placement, key rotation, scopes, issuer validation, and service-to-service identity.
3. Object and function authorisation: test across users, roles, tenants, and object identifiers.
4. Property-level controls: test mass assignment, excessive data exposure, and writable sensitive fields.
5. Resource limits: evaluate pagination, query depth, batch size, upload size, timeout, and rate limits.
6. Error and metadata handling: check stack traces, schema leakage, debug endpoints, and inconsistent status codes.
7. Workflow and webhook security: verify signatures, timestamp windows, replay prevention, origin validation, and state transitions.
8. Versioning and configuration: ensure old versions do not retain weaker controls and that administrative endpoints are not publicly exposed.

GraphQL requires attention to introspection exposure, field-level authorisation, query depth and cost, aliases, batching, resolver data access, and error detail. Disabling introspection alone does not secure a GraphQL service.

API gateways can centralise authentication, throttling, and observability, but they cannot replace authorisation inside the service that understands object ownership and business context.

7. Database and Data-Layer Assessment

Database security involves application queries, database accounts, network placement, configuration, backups, replicas, logs, and administrative access. The principle of least privilege should apply separately to read, insert, update, delete, schema-change, and administrative capabilities.

Assessment should examine:

• parameterised queries and ORM behaviour;
• service-account privileges and separation of duties;
• database network exposure and encrypted connections;
• encryption at rest and key-management practices;
• sensitive-data minimisation, masking, retention, and deletion;
• backup security and restoration testing;
• audit logging, alerting, and protection from log injection;
• row-level or tenant-level isolation where required;
• secrets in connection strings, source repositories, and deployment manifests.

Encryption reduces exposure if media or backups are stolen, but it does not prevent an authorised application account from reading data. Access governance, tokenisation, minimisation, and monitoring remain necessary. Hashing is appropriate for verification values such as passwords when a suitable password-hashing scheme is used; it is not a general replacement for encryption when the original value must later be recovered.

Database testing must avoid altering production records. Read-only metadata checks, synthetic records, replicas, and pre-approved queries are safer than broad extraction. Findings should distinguish direct database exposure from application-mediated access, because remediation differs.

8. Secure Software and Supply-Chain Assessment

Software risk extends to open-source packages, build tools, container images, source repositories, CI/CD runners, plugins, infrastructure code, and third-party services. A dependency may be vulnerable, malicious, abandoned, compromised, or incorrectly configured.

A mature software supply-chain programme includes:

• a software bill of materials (SBOM) with component names, versions, and provenance;
• dependency pinning and integrity verification, balanced with an update process;
• vulnerability monitoring and risk-based remediation;
• protected branch and release controls;
• signed commits, artefacts, or provenance attestations where appropriate;
• isolated, ephemeral build runners with minimal credentials;
• secret scanning and prevention of secret publication;
• review of transitive dependencies and package maintainers;
• container image minimisation, non-root execution, and runtime restrictions;
• reproducible or independently verifiable builds where feasible.

An SBOM is an inventory, not proof that software is secure. Vulnerability scanners may produce false positives, miss vulnerabilities, or report a vulnerable package that is unreachable in the deployed configuration. Triage should consider exploitability, reachability, exposure, compensating controls, and patch availability.

CI/CD systems are high-value targets because compromise can create a trusted malicious release. Build identities should have narrowly scoped permissions, production deployment should require appropriate approval or policy checks, and artefacts should be promoted rather than rebuilt inconsistently between environments.

9. DevSecOps Controls and Verification

DevSecOps integrates security into the software lifecycle rather than placing all testing at release time. Controls should be selected according to risk and developer workflow.

Security gates should be risk-based. Blocking every theoretical scanner warning encourages suppression and bypass. Conversely, critical exploitable findings in exposed services should block release or require formally documented risk acceptance. Security champions, reusable secure components, developer training, and clear remediation ownership improve adoption.

AI-assisted coding and testing can increase productivity but introduces risks: generated code may contain insecure assumptions, licensing or provenance may be unclear, prompts may expose confidential information, and automated findings may be over-trusted. Human review, approved models and tools, data-handling rules, tests, and secure coding standards remain essential.

10. Reporting, Remediation and Retesting

A useful finding is reproducible, bounded, and actionable. It should contain:

• title and affected asset;
• severity and business context;
• concise description and security property violated;
• prerequisites and safe reproduction steps;
• evidence, such as redacted requests and responses;
• impact and plausible abuse path;
• root cause;
• remediation guidance;
• references to relevant requirements or standards;
• owner, target date, and retest status.

Remediation should address the root cause rather than merely hide the symptom. For example, changing an object identifier format may reduce casual enumeration but does not fix missing ownership checks. A strong retest verifies the fix, tests neighbouring paths, and checks for regression. Closure should record residual risk, compensating controls, and evidence rather than relying on a verbal assertion.

Applied Case: Illustrative Multi-Tenant Billing API

Background

A fictional company, Northstar Billing, provides a multi-tenant invoicing platform. Customers use a web portal and mobile application backed by a REST API. The assessment is authorised in a staging environment populated with synthetic records. The objective is to evaluate tenant isolation, payment workflows, and software-delivery controls.

Problem

The API documentation exposes an endpoint resembling /v2/invoices/{id}. A standard customer token can retrieve an invoice belonging to another tenant when the numeric identifier is changed. The user interface does not display the foreign invoice, but the API response contains customer names, billing addresses, and line items. A second test shows that a client can submit a status property when updating an invoice. Finally, the CI pipeline downloads an unpinned third-party build action with a token capable of publishing releases.

Analysis

The first issue is broken object-level authorisation and a tenant-isolation failure. The identifier format contributes to discoverability, but unpredictability would not be a sufficient fix. The service must check that the authenticated principal is authorised for the specific invoice and tenant. The second issue is property-level authorisation failure or mass assignment: clients should not control server-managed workflow fields. The third issue is supply-chain and CI privilege risk. Compromise of the action or its download path could produce a trusted malicious artefact.

The assessor records requests using synthetic identities from two tenants, confirms the expected denial, and avoids accessing real data. Architecture review shows that the API service trusts a tenant claim from a token but does not compare it with the invoice’s stored tenant identifier. Code review confirms that request JSON is bound directly to a persistence model. Pipeline review confirms broad release credentials and no integrity pinning.

Approach and solution

The remediation plan is sequenced by risk:

1. Add server-side object and tenant authorisation in the service layer, with negative tests for cross-tenant access.
2. Replace direct model binding with an explicit update DTO containing only permitted fields; calculate status transitions from authorised workflow operations.
3. Add policy tests for every role and tenant boundary, including API and background-job paths.
4. Pin the build action to a reviewed immutable reference, reduce token permissions, isolate runners, and require protected release approval.
5. Generate an SBOM, monitor dependencies, and add a pipeline policy that prevents unreviewed release artefacts.
6. Retest the original paths and adjacent endpoints, then conduct a regression and workflow review.

Outcome

After remediation, cross-tenant requests return a consistent denial, server-managed fields are ignored or rejected, and workflow transitions require authorised operations. The release pipeline uses a narrowly scoped identity and reviewed dependencies. Monitoring records denied cross-tenant attempts without logging sensitive invoice content.

Learning points

The case demonstrates that application security is a system property. A secure token does not compensate for missing object checks; schema validation does not establish business authority; and a secure application can still be undermined by an untrusted build process. Effective assessment connects technical evidence to data ownership, process states, and delivery infrastructure.

Challenges and Limitations

No assessment proves the absence of vulnerabilities. Time, test data, undocumented functionality, feature flags, third-party dependencies, and environment differences limit coverage. Automated tools are valuable for repeatability but may miss business logic, access-control context, and chained attacks. Manual testing is richer but depends on skill and can be inconsistent.

Production systems create safety, privacy, and availability constraints. Testing may expose personal data or trigger detection and response processes. Legal authority can vary by jurisdiction, especially for cross-border services and third-party platforms. Assessors must minimise collection, redact evidence, encrypt reports, control retention, and disclose urgent risks promptly.

Standards also evolve. OWASP categories and versions change, cloud services introduce new controls, and vulnerability databases may disagree. Reports should identify the framework version or assessment basis and explain professional judgement rather than treating a category label as a complete analysis.

Best-Practice Checklist

• Obtain written scope and explicit permission.
• Map assets, identities, trust boundaries, and sensitive workflows.
• Inventory web, API, administrative, legacy, and partner interfaces.
• Test authorisation for every role, tenant, object, property, and workflow state.
• Use parameterised queries and context-appropriate encoding.
• Protect credentials, sessions, secrets, logs, backups, and error responses.
• Apply rate, size, depth, timeout, and concurrency limits.
• Maintain dependency inventories, SBOMs, provenance, and secure CI/CD identities.
• Prefer safe synthetic data and non-destructive evidence collection.
• Report root causes, business impact, owners, deadlines, and residual risk.
• Retest fixes and add regression tests to prevent recurrence.

Chapter Summary

Web, API, database, and secure-software assessment requires more than discovering technical defects. It requires authorised scope, threat modelling, context-sensitive input handling, strong authentication and session management, server-side access control, and deliberate testing of business workflows. API assessments must address object ownership, property exposure, resource limits, versioning, webhooks, and GraphQL-specific risks. Database security depends on least privilege, network and backup protection, data minimisation, auditing, and safe query construction.

The software supply chain and CI/CD pipeline are part of the attack surface. SBOMs, dependency governance, protected builds, signed or verifiable artefacts, secret management, and narrowly scoped identities reduce systemic risk. DevSecOps distributes security controls across design, coding, build, test, deployment, operation, and learning. Findings should be evidence-based, business-aware, actionable, and retested. Ethical practice requires permission, minimisation of harm, privacy protection, and responsible communication.

Key Terms

Threat modelling: Structured identification of assets, threats, trust boundaries, and mitigations.

Input validation: Checking data type, structure, range, length, and permitted content.

Canonicalisation: Converting data to a defined representation before security decisions.

Injection: Causing data to be interpreted as commands or executable instructions.

XSS: Execution of attacker-controlled script in a user’s browser context.

SSRF: Causing a server to make an attacker-influenced network request.

Authentication: Establishing the identity of a subject.

Authorisation: Determining whether a subject may perform an action on a resource.

Session: Server-associated state or credential representing an authenticated interaction.

CSRF: Unauthorised action induced through a victim’s authenticated browser.

Object-level authorisation: Checking permission for a particular data object.

Tenant isolation: Preventing one customer organisation from accessing another’s data or functions.

Business logic: Rules governing valid business operations and state transitions.

Idempotency: Property whereby safe repetition of an operation has the intended single effect.

SBOM: Software bill of materials listing components and provenance information.

Supply-chain risk: Risk arising from software, tools, dependencies, suppliers, or build processes.

DevSecOps: Integration of security practices throughout software delivery and operation.

SAST: Static application security testing of source or compiled code.

DAST: Dynamic application security testing against a running application.

Retest: Follow-up assessment verifying remediation and regression resistance.

Review Questions

5 Short Answer Questions

1. Why is input validation not a substitute for authorisation?
2. State two security properties of a session cookie and explain their purpose.
3. What is broken object-level authorisation?
4. Why is an SBOM not proof that software is secure?
5. Identify two controls that reduce CI/CD supply-chain risk.

5 Long Answer Questions

1. Explain how an assessor should plan a safe and ethical test of a public REST API.
2. Compare authentication, session management, and authorisation, using an example of account takeover or privilege escalation.
3. Discuss how parameterised queries, least-privilege database accounts, encryption, and monitoring address different database risks.
4. Explain why business-logic vulnerabilities are difficult for automated scanners to identify and describe suitable testing methods.
5. Design a risk-based DevSecOps control programme covering design, coding, build, test, deployment, and operation.

3 Analytical / Application Questions

1. A customer can change an invoice identifier and retrieve another tenant’s invoice. Analyse the root cause, evidence required, impact, and remediation. Explain why changing identifiers alone is inadequate.
2. A GraphQL API permits deeply nested queries and returns fields that the client does not need. Develop an assessment plan and recommend controls for authorisation, query cost, data minimisation, and monitoring.
3. A release pipeline uses an unpinned external action and a credential that can publish production artefacts. Evaluate the threat path and propose a prioritised remediation and retesting strategy.

Multiple Choice Questions with Answers

Question 1

Which control directly addresses broken object-level authorisation?

A. Checking that the requested object belongs to the authenticated user or tenant

B. Changing numeric identifiers to longer numbers

C. Disabling browser caching

D. Adding a graphic CAPTCHA to the login page

Correct Answer: A. Checking that the requested object belongs to the authenticated user or tenant

Question 2

What is the primary defence against SQL injection when application data is used in a query?

A. Hiding database error messages only

B. Using parameterised queries or prepared statements

C. Encoding all values as HTML

D. Increasing database storage capacity

Correct Answer: B. Using parameterised queries or prepared statements

Question 3

Which statement about JWTs is correct?

A. A signed JWT is automatically encrypted

B. JWTs eliminate the need to validate expiry and audience

C. JWT validation should include signature, issuer, audience, expiry, and algorithm policy

D. JWTs are safe when placed in URLs

Correct Answer: C. JWT validation should include signature, issuer, audience, expiry, and algorithm policy

Question 4

What is the main purpose of an SBOM?

A. To replace penetration testing

B. To inventory software components and support provenance and vulnerability management

C. To encrypt database backups

D. To enforce browser cookie attributes

Correct Answer: B. To inventory software components and support provenance and vulnerability management

Question 5

Which finding is an example of property-level authorisation failure?

A. A user submits a server-managed account-status field and changes it

B. A server rejects an unsupported media type

C. A password is hashed with a suitable password-hashing scheme

D. A cookie is marked Secure

Correct Answer: A. A user submits a server-managed account-status field and changes it

Question 6

Why should API rate and resource limits be assessed?

A. To ensure every endpoint returns HTML

B. To reduce risks such as resource exhaustion and abusive automation

C. To make object authorisation unnecessary

D. To disable all partner integrations

Correct Answer: B. To reduce risks such as resource exhaustion and abusive automation

Question 7

Which practice best reduces the impact of a compromised CI build action?

A. Give the action permanent administrator credentials

B. Use broad shared credentials for convenience

C. Use an immutable reviewed reference and narrowly scoped permissions

D. Disable all build logging

Correct Answer: C. Use an immutable reviewed reference and narrowly scoped permissions

Question 8

Which statement best describes CSRF risk?

A. It concerns server-side SQL parsing only

B. It exploits browsers automatically attaching authentication credentials to requests

C. It is prevented by using longer database table names

D. It occurs only in command-line applications

Correct Answer: B. It exploits browsers automatically attaching authentication credentials to requests

Question 9

Why is changing an object identifier format insufficient to fix tenant isolation?

A. Identifiers are unrelated to databases

B. Authorisation must still verify ownership or tenant permission on the server

C. It prevents all logging

D. It disables encryption

Correct Answer: B. Authorisation must still verify ownership or tenant permission on the server

Question 10

What should a professional vulnerability report include?

A. Only a severity label

B. Unredacted production data for maximum credibility

C. Reproducible evidence, impact, root cause, remediation, owner, and retest status

D. A claim that no other vulnerabilities exist

Correct Answer: C. Reproducible evidence, impact, root cause, remediation, owner, and retest status