API Penetration Testing: How to Find Security Risks

APIs have become the backbone of modern digital applications. Mobile applications, web platforms, cloud services, SaaS products, payment systems, partner integrations, and internal enterprise applications increasingly depend on APIs to exchange data and execute business functions. As this dependence grows, APIs also become an attractive target for attackers.

An API can expose authentication functions, customer information, financial records, business workflows, administrative operations, and integrations with other systems. A vulnerability in an API may therefore have a much larger impact than a weakness in an individual web page. An attacker who discovers an authorization flaw, excessive data exposure, weak authentication mechanism, or business logic vulnerability may be able to access information or perform actions that the application was never designed to allow.

This is why API penetration testing has become an important part of application security programmes. API penetration testing goes beyond automated vulnerability scanning. It involves understanding how an API works, identifying its attack surface, analysing authentication and authorization controls, manipulating requests, testing business logic, validating vulnerabilities, and determining how weaknesses could affect the business.

This guide explains how organizations can approach API penetration testing, what security risks should be assessed, how vulnerabilities should be validated, and how enterprises can turn testing results into measurable security improvements.

What Is API Penetration Testing?

API penetration testing is an authorized security assessment designed to identify and validate vulnerabilities in application programming interfaces.

The objective is not simply to discover technically incorrect configurations. A professional penetration test attempts to determine whether an attacker could exploit weaknesses to gain unauthorized access, manipulate application functionality, expose sensitive information, bypass security controls, or compromise business workflows.

API testing normally involves multiple layers of assessment. The tester examines how the API identifies users, how permissions are enforced, how requests are processed, how data is returned, how sessions and tokens are managed, and whether business rules can be manipulated.

The most important distinction is between scanning and penetration testing. A scanner may identify a missing security header, an outdated component, or a potentially vulnerable endpoint. A penetration tester attempts to understand the application's actual security model and validate whether a weakness can produce meaningful impact.

For APIs, this distinction is particularly important because many serious vulnerabilities are related to application logic rather than easily detectable technical signatures.

Why API Security Matters

APIs frequently sit between users and sensitive backend systems. They may connect a mobile application to customer databases, expose services to business partners, or allow internal applications to communicate with cloud infrastructure.

An API request can potentially trigger actions such as creating an account, transferring funds, changing a password, downloading a document, updating an order, modifying permissions, or retrieving customer records.

The security of these operations depends on more than authentication. An API may correctly identify a user while still allowing that user to access another customer's data. It may validate a token while failing to enforce permissions at the individual object level. It may protect an endpoint while allowing the underlying business workflow to be manipulated through another endpoint.

This creates a fundamental security principle: authentication does not automatically mean authorization.

A user being successfully logged in only proves who the user is. The API must separately determine what that user is allowed to access and what actions that user is permitted to perform.

Understanding the API Attack Surface

Before testing vulnerabilities, penetration testers need to understand the API attack surface.

Modern organizations may operate hundreds or thousands of endpoints across production applications, mobile applications, partner integrations, internal services, development environments, and legacy systems. Some endpoints may be documented while others may remain undocumented.

The attack surface can include REST APIs, GraphQL APIs, SOAP services, WebSocket interfaces, mobile backends, authentication endpoints, administrative APIs, internal APIs exposed through cloud infrastructure, and third-party integrations.

An effective assessment therefore begins with discovery.

API Discovery

API documentation is an important starting point, but it should not automatically be treated as a complete representation of the attack surface.

OpenAPI or Swagger documentation may identify known endpoints, parameters, request formats, response structures, and authentication requirements. However, undocumented endpoints, deprecated APIs, legacy versions, administrative functions, and hidden parameters may still exist.

A penetration tester can compare documentation with actual application traffic and backend behaviour to identify discrepancies.

These discrepancies can reveal important security risks. For example, an organization may believe that an older API version is no longer accessible while the endpoint remains publicly reachable. Similarly, documentation may describe an endpoint as requiring a particular role even though the server does not enforce that requirement.

Endpoint Enumeration

Endpoint enumeration involves identifying API paths, HTTP methods, parameters, headers, request bodies, authentication mechanisms, and response patterns.

The objective is to understand what functionality exists and where security controls are applied.

An endpoint should not be evaluated in isolation. Its relationship with other endpoints may reveal attack paths that are not visible when testing individual requests.

For example, an attacker may obtain an identifier from one endpoint, use that identifier in another endpoint, and then manipulate a third endpoint to perform an unauthorized action.

Authentication Testing

Authentication testing determines whether the API properly establishes and maintains user identity.

Weak authentication controls can allow attackers to impersonate legitimate users or obtain access to protected resources.

Testing should examine login mechanisms, token generation, password policies, multi-factor authentication, account recovery, session termination, token expiration, and authentication state transitions.

Token Security

Modern APIs frequently use access tokens such as JWTs or opaque session tokens.

Testing should determine whether tokens are sufficiently protected, whether they expire appropriately, whether revoked credentials remain usable, and whether sensitive information is unnecessarily embedded in tokens.

JWT implementations require particular attention to signature validation, algorithm handling, token claims, expiration, audience validation, issuer validation, and key management.

A token should not be trusted merely because it has the expected structure. The server must independently validate the security properties that determine whether the token is legitimate and appropriate for the requested operation.

Session Lifecycle

Security should also be evaluated throughout the complete session lifecycle.

A secure implementation should account for login, token issuance, token refresh, logout, password changes, account recovery, privilege changes, and session expiration.

If a token continues to work after a security-sensitive event when it should have been invalidated, an attacker who obtains that token may retain access longer than intended.

Authorization Testing

Authorization is one of the most important areas of API penetration testing.

A system can have strong authentication and still be fundamentally insecure if authorization decisions are incorrectly implemented.

The tester evaluates whether every sensitive operation verifies that the authenticated identity has the required permission to perform that specific action on that specific resource.

Horizontal Access

Horizontal authorization testing examines whether one user can access another user's resources.

Consider an API request such as:

GET /api/customers/1042/orders

If user A can replace 1042 with another customer's identifier and retrieve that customer's orders, the API may contain an object-level authorization vulnerability.

This class of issue is particularly dangerous because the attacker may not need administrative privileges. A normal authenticated account may be sufficient.

Vertical Access

Vertical authorization testing examines privilege boundaries between different roles.

For example, an application may have customer, support, manager, and administrator roles. The penetration tester determines whether a lower-privileged account can invoke administrative functions by directly calling protected endpoints.

Simply hiding administrative functionality from the user interface is not a security control. Authorization must be enforced on the server.

Tenant Isolation

Multi-tenant applications require additional testing.

A user from one organization should not be able to access another organization's customers, invoices, documents, reports, configurations, or administrative functions.

Tenant identifiers should not be treated as trustworthy simply because they are supplied by an authenticated client. The server must establish the relationship between the authenticated identity and the requested tenant.

Input Validation Testing

APIs accept data from clients, and that data should always be treated as untrusted.

Testing involves modifying parameters, request bodies, headers, identifiers, data types, lengths, encoding, nested objects, and unexpected values.

The objective is to determine whether the application validates input consistently and safely.

An API may expect an integer but receive a string. It may expect a predefined status value but receive an unexpected state. It may expect one object but receive an array or deeply nested structure.

These cases can expose type confusion, validation weaknesses, application errors, or unexpected business behaviour.

Injection Vulnerabilities

Injection vulnerabilities occur when attacker-controlled input reaches an interpreter or backend component in an unsafe manner.

API penetration testing may assess SQL injection, NoSQL injection, command injection, LDAP injection, template injection, expression injection, and other context-specific injection conditions.

SQL Injection

SQL injection occurs when untrusted input influences database queries in an unsafe manner.

Testing should determine whether API parameters, JSON fields, query parameters, filters, sorting functions, and search functionality are safely handled.

A vulnerable API may expose customer information, authentication records, transaction data, or other sensitive database content.

Modern applications frequently use parameterized queries and ORM frameworks, but secure frameworks do not eliminate the need for testing. Unsafe dynamic queries, raw SQL functionality, or incorrect query construction can still introduce vulnerabilities.

Command Injection

If an API passes user-controlled values to operating-system commands, command injection may become possible.

Potentially affected functionality can include file conversion, diagnostic operations, network utilities, document processing, image manipulation, or system administration features.

The impact can be severe because successful command execution may provide access to the underlying server.

Broken Object-Level Authorization

Broken Object-Level Authorization, commonly associated with APIs that expose direct object identifiers, deserves specific attention.

Applications often use identifiers for customers, invoices, documents, orders, tickets, or transactions. If the API accepts these identifiers without validating ownership or authorization, users may manipulate them to access resources belonging to others.

The important question during testing is not whether an identifier can be changed. The important question is whether changing it allows an unauthorized security boundary to be crossed.

This distinction separates simple parameter manipulation from a validated security vulnerability.

Excessive Data Exposure

APIs sometimes return more information than the client actually needs.

A mobile application may require a customer's name and profile image but receive internal identifiers, administrative metadata, account information, or other sensitive fields in the same response.

Even when the front-end hides those fields, the data has already been delivered to the client.

Penetration testing should therefore inspect complete API responses rather than only what is visibly displayed in the application.

The security principle is straightforward: APIs should return only the information required for the intended function.

Mass Assignment

Mass assignment vulnerabilities can occur when APIs automatically bind user-controlled fields to backend objects.

Imagine an account update endpoint that accepts:

name

email

phone

If the backend automatically accepts additional fields such as role, isAdmin, or accountStatus, an attacker may attempt to manipulate properties that should only be controlled internally.

Testing should identify which fields can be modified by clients and whether sensitive properties are explicitly protected.

This is particularly important for JSON-based APIs and frameworks that automatically map request objects to backend models.

API Rate Limiting

Rate limiting is an important defensive control for APIs exposed to the internet.

Testing can examine whether sensitive endpoints appropriately restrict repeated requests.

Authentication endpoints, password reset functions, OTP validation, search APIs, resource-intensive operations, and transaction functions may require stronger protections than ordinary read operations.

A lack of effective rate limiting can enable credential attacks, enumeration, automated abuse, resource exhaustion, and business logic exploitation.

Rate limiting should also be evaluated in the context of distributed clients and different authentication states. A control that blocks repeated requests from one IP address may not be sufficient if an attacker can distribute requests across multiple sources.

Business Logic Testing

Some of the most serious API vulnerabilities cannot be detected reliably by automated scanners because they depend on understanding how the business works.

Business logic testing evaluates whether application workflows can be manipulated in ways that violate business rules.

Workflow Manipulation

Consider an online purchasing workflow that follows:

Cart → Payment → Order Confirmation → Shipment.

A tester may investigate whether steps can be skipped, repeated, reordered, or performed with inconsistent state.

The same principle applies to banking, healthcare, insurance, travel, SaaS, HR, and enterprise workflows.

The API may technically accept every request while the sequence itself violates the intended business process.

Transaction Abuse

Financial and transactional APIs require additional scrutiny.

Testing may examine whether amounts can be modified after authorization, whether transaction states can be replayed, whether discounts can be reused, or whether users can manipulate identifiers associated with transactions.

The purpose is not to cause real-world financial impact during an authorized assessment. Instead, the tester safely validates whether the application contains a condition that could allow such abuse.

GraphQL Security Testing

GraphQL introduces a different API security model because clients can construct queries based on an exposed schema.

Testing can include schema exposure, authorization at resolver level, excessive query depth, resource-intensive queries, introspection configuration, field-level authorization, and abuse of nested relationships.

A GraphQL API may have strong endpoint-level authentication while still exposing sensitive fields through insufficient resolver authorization.

This demonstrates why security testing must consider the architecture and technology model of the API rather than applying the same checklist to every interface.

API Key Security

API keys are commonly used for application-to-application communication and third-party integrations.

Testing should determine whether keys are exposed in source code, mobile applications, client-side JavaScript, repositories, configuration files, logs, or API responses.

The presence of an API key does not automatically mean that the system is secure. Organizations should also determine what permissions the key provides and whether the key can be restricted by environment, application, network, scope, or function.

A leaked key with excessive privileges can create significant risk.

Sensitive Information in Errors

Error responses can reveal valuable information to attackers.

An API may expose database errors, internal class names, file paths, framework information, debugging information, stack traces, or identifiers.

Error handling should provide enough information for legitimate clients while avoiding unnecessary internal details.

Testing should therefore include malformed requests, missing parameters, invalid authentication, unauthorized access attempts, unsupported methods, invalid content types, and unexpected data structures.

Security Headers and Transport Security

API security also depends on the underlying transport and infrastructure.

Testing should verify that sensitive API traffic is protected through appropriate TLS configuration and that insecure protocols or unnecessary HTTP exposure are not permitted.

Where APIs interact with browsers, relevant HTTP security controls should also be evaluated.

Transport security cannot compensate for application-level authorization flaws, but weak transport controls can expose credentials, tokens, and sensitive information while it is being transmitted.

CORS Configuration

Cross-Origin Resource Sharing, or CORS, should be assessed for APIs that are accessed by browser-based applications.

An overly permissive configuration may allow untrusted origins to interact with sensitive APIs under conditions that were not intended by the application owner.

Testing should evaluate allowed origins, credentials, methods, headers, and preflight behaviour.

The correct configuration depends on the application's architecture. A permissive policy is not automatically vulnerable, but unnecessary trust relationships should be carefully examined.

API Versioning

API versioning introduces another potential security challenge.

Organizations may deploy newer API versions while older endpoints remain accessible for compatibility reasons. These older versions may not receive the same security controls or security fixes.

Penetration testers should therefore assess whether deprecated endpoints remain reachable and whether authorization, validation, and data protection controls are consistent across versions.

An organization should know which APIs are active, which are deprecated, and which should be removed.

Third-Party API Integrations

Modern applications rarely operate independently.

They may connect to payment gateways, identity providers, CRM systems, cloud services, messaging platforms, analytics providers, and other third-party services.

The security assessment should determine what trust relationships exist between these systems.

A vulnerability in the organization's application may expose third-party credentials, while a compromised integration may provide a path into the organization's environment.

Testing should therefore consider API credentials, webhook security, callback validation, authorization scopes, signature verification, data exchange, and failure handling.

Webhooks and Callback Security

Webhooks allow external systems to send events to an organization's API.

Because these endpoints often accept requests from external systems, they require strong validation.

Testing should evaluate whether webhook requests are authenticated, whether signatures are correctly validated, whether replay attacks are possible, and whether attackers can inject fraudulent events.

A compromised webhook can potentially trigger actions inside the organization's environment without directly compromising the main application.

API Logging and Monitoring

Security controls are incomplete if malicious API activity cannot be detected.

API logging should provide sufficient information to identify authentication failures, authorization violations, unusual request volumes, suspicious parameter changes, administrative actions, and other security-relevant events.

However, logging must be implemented carefully. Access tokens, passwords, API keys, personal data, and other sensitive information should not unnecessarily appear in logs.

During a penetration test, the tester can also evaluate whether significant attack activity would generate useful security telemetry.

This connects API penetration testing with SOC and incident response capabilities.

Automated Scanning vs Manual API Penetration Testing

Automated tools are useful for discovering common vulnerabilities and performing repetitive checks.

They can help identify exposed endpoints, missing security controls, injection indicators, insecure configurations, and known patterns.

However, automated scanning cannot reliably understand every application's authorization model or business logic.

A scanner may identify an endpoint that accepts an object identifier. It may not understand that the identifier belongs to another customer and that accessing it violates tenant isolation.

Manual testing provides the contextual analysis required to identify these deeper vulnerabilities.

The strongest API security programmes therefore combine automation with manual assessment rather than treating either approach as a complete solution.

API Penetration Testing Methodology

A structured API penetration test normally begins with planning and scope definition.

The organization should identify the APIs to be tested, environments, domains, authentication requirements, test accounts, business functions, data classifications, testing windows, and limitations.

The rules of engagement should clearly define what activities are authorized.

Once scope is established, the tester performs reconnaissance and API discovery. Documentation, application traffic, endpoint enumeration, technology identification, and authentication flows are examined to establish an accurate attack surface.

The next stage involves authentication and authorization testing. Test accounts with different roles should be used wherever possible because privilege boundaries cannot be assessed effectively with a single account.

The tester then examines input validation, injection vulnerabilities, data exposure, session controls, rate limiting, API configuration, business logic, third-party integrations, and other application-specific risks.

Potential vulnerabilities are manually validated to determine exploitability and impact.

The final stage involves reporting, remediation support, and retesting.

Risk-Based Vulnerability Assessment

Not every API vulnerability represents the same level of business risk.

A missing security header on a low-risk endpoint may have significantly less impact than an authorization vulnerability that exposes financial records.

Risk assessment should therefore consider more than technical severity.

Exploitability

The tester evaluates how difficult exploitation would be, what access is required, whether authentication is necessary, and whether exploitation can be automated.

Impact

Impact considers confidentiality, integrity, and availability as well as potential operational and financial consequences.

Business Context

Business context is essential.

A vulnerability affecting a customer profile API may have different consequences from the same vulnerability affecting a payment or administrator API.

Organizations should therefore prioritize vulnerabilities according to actual business exposure rather than relying solely on generic severity scores.

API Vulnerability Chaining

Attackers rarely think only in terms of isolated vulnerabilities.

A low-severity information disclosure issue may reveal an identifier that enables an authorization bypass. A weak API key may expose an endpoint that contains sensitive data. A business logic weakness may become significantly more serious when combined with insufficient rate limiting.

Penetration testing should therefore evaluate attack paths.

The objective is to understand whether several individually moderate weaknesses can be combined into a high-impact compromise.

This is one of the areas where experienced manual penetration testers can provide significantly more value than automated scanning alone.

Evidence and Proof of Concept

Every confirmed vulnerability should have sufficient evidence to demonstrate the security issue.

Evidence may include sanitized API requests and responses, screenshots, response comparisons, relevant headers, authentication context, and controlled proof-of-concept results.

Testing should avoid unnecessary exposure of sensitive production information.

The goal of a proof of concept is to demonstrate the vulnerability clearly without causing avoidable operational impact.

A good finding should allow the development and security teams to reproduce the issue and understand why it occurred.

API Penetration Testing Report

A professional report should serve both technical and executive audiences.

The executive section should explain the overall security posture, major risks, business impact, and remediation priorities.

The technical section should provide detailed vulnerability findings.

Each finding should clearly explain the affected endpoint or function, vulnerability description, security impact, evidence, reproduction methodology, severity, root cause, and remediation guidance.

Weak reporting often reduces the value of a technically strong assessment. If development teams cannot understand what needs to change, vulnerabilities may remain unresolved.

Remediation After API Testing

Remediation should address the underlying security weakness rather than simply modifying the specific request that was used during testing.

For authorization vulnerabilities, this may require centralized server-side authorization checks rather than filtering a particular parameter.

For excessive data exposure, developers may need to redesign response objects and explicitly define fields that can be returned.

For injection vulnerabilities, secure query construction and appropriate input handling should be implemented.

For business logic vulnerabilities, application workflows may need additional server-side state validation.

Security fixes should also be reviewed for regression risk because changes to authorization or validation controls can unintentionally affect legitimate functionality.

Retesting

Retesting is an essential part of API penetration testing.

A vulnerability should not be considered closed merely because a developer reports that a fix has been implemented.

The tester should verify that the original attack condition has been eliminated and that the remediation has not introduced another weakness.

For example, if an authorization vulnerability is fixed for one endpoint, related endpoints should be reviewed to determine whether the same underlying authorization logic remains vulnerable elsewhere.

This is particularly important when the root cause is architectural rather than isolated to a single endpoint.

API Security in the Software Development Lifecycle

API security should not begin when a penetration test starts.

Security requirements should be considered during API design, development, testing, deployment, and maintenance.

Developers should define authentication and authorization requirements before implementation. Security-sensitive fields should be identified during API design. Automated security testing can be incorporated into CI/CD pipelines, while periodic manual penetration testing can provide deeper validation.

Threat modelling can also help identify potential abuse cases before APIs reach production.

This approach moves API security from a periodic compliance activity toward continuous application risk management.

Common API Penetration Testing Mistakes

Scanner Dependency

Relying entirely on automated scanners can leave authorization and business logic vulnerabilities undiscovered.

Limited Scope

Testing only documented production endpoints can miss legacy APIs, administrative interfaces, partner APIs, and undocumented functionality.

Single Account

Using only one test account prevents meaningful analysis of role-based and object-level authorization.

No Business Context

Testing technical vulnerabilities without understanding business workflows can result in important security risks being overlooked.

No Retesting

Without validation after remediation, organizations cannot confidently determine whether vulnerabilities have actually been resolved.

Building a Mature API Security Programme

Organizations with large API ecosystems should treat API security as an ongoing programme rather than an annual penetration test.

An API inventory should provide visibility into active, deprecated, internal, external, and third-party interfaces.

Security teams should establish ownership for APIs and define security requirements based on data sensitivity and business criticality.

High-risk APIs should receive stronger authentication, authorization, monitoring, rate limiting, and testing controls.

Security testing should be integrated into application development while independent penetration testing should periodically validate the effectiveness of those controls.

Organizations should also monitor API activity after deployment because security risk changes as APIs evolve.

How Often Should APIs Be Penetration Tested?

There is no universal testing frequency that applies equally to every API.

High-risk APIs should generally be assessed more frequently, particularly when they process financial information, personal data, healthcare information, authentication credentials, or sensitive enterprise data.

Testing should also be considered after significant architectural changes, major feature releases, authentication changes, migration to new infrastructure, introduction of new integrations, or substantial changes to business logic.

A newly launched high-risk API should not wait for an annual testing cycle before receiving a security assessment.

Choosing an API Penetration Testing Provider

Organizations should evaluate a provider based on methodology, tester expertise, technical depth, reporting quality, and ability to understand business risk.

A provider should demonstrate experience with authentication, authorization, REST, GraphQL, API gateways, mobile backends, cloud environments, business logic, and enterprise integrations.

The quality of the final report is equally important. A report should provide actionable technical findings while giving management a clear understanding of business exposure.

The provider should also support remediation and retesting rather than treating the engagement as complete when the initial report is delivered.

API Penetration Testing for Enterprises

Enterprise API ecosystems are often complex because they combine internal services, public APIs, partner integrations, mobile applications, cloud platforms, and legacy systems.

This complexity makes centralized visibility and consistent security controls difficult.

An enterprise API penetration testing programme should therefore examine not only individual endpoints but also relationships between systems.

The assessment should consider identity boundaries, tenant isolation, data flows, privileged operations, third-party integrations, API gateways, monitoring, and business workflows.

The objective is to answer a broader question:

Can an attacker use the organization's API ecosystem to cross a security boundary or perform an action they should not be able to perform?

That question is more valuable than simply asking whether an API has vulnerabilities.

A Practical API Penetration Testing Lifecycle

A mature API penetration testing lifecycle can be summarized as:

Plan → Discover → Map → Authenticate → Authorize → Manipulate → Validate → Exploit → Report → Remediate → Retest

Planning establishes scope and rules of engagement.

Discovery identifies the API attack surface.

Mapping establishes endpoints, parameters, roles, data flows, and workflows.

Authentication testing evaluates identity controls.

Authorization testing examines privilege and object boundaries.

Manipulation tests how the API responds to unexpected or malicious input.

Validation confirms whether suspected weaknesses are exploitable.

Controlled exploitation demonstrates business impact.

Reporting communicates findings and priorities.

Remediation addresses root causes.

Retesting verifies that security weaknesses have been effectively resolved.

Final API Penetration Testing Checklist

Before considering an API security assessment complete, organizations should ensure that authentication and authorization have been tested across relevant user roles.

Object-level access, function-level access, tenant isolation, token security, session management, input validation, injection risks, excessive data exposure, mass assignment, rate limiting, business logic, API versioning, third-party integrations, webhooks, CORS, GraphQL functionality, API keys, logging, and error handling should be considered according to the application's architecture.

The assessment should also include manual validation of important findings, risk-based prioritization, clear remediation guidance, and post-remediation retesting.

Most importantly, organizations should ensure that API security findings are connected to actual business risk.

Conclusion

APIs are now fundamental to modern digital infrastructure, but their importance also makes them a high-value target for attackers.

Effective API penetration testing goes far beyond running a vulnerability scanner against a list of endpoints. It requires understanding application architecture, authentication, authorization, data flows, user roles, business processes, integrations, and the security boundaries that protect sensitive functionality.

The most serious API vulnerabilities are often not obvious technical flaws. They can emerge when legitimate functionality is combined in an unintended way, when authorization is inconsistently enforced, when sensitive data is returned unnecessarily, or when business rules can be manipulated.

A mature API security strategy therefore combines secure API design, development-time controls, automated security testing, manual penetration testing, continuous monitoring, vulnerability management, and retesting.

For organizations handling sensitive customer, financial, healthcare, government, or enterprise data, API security should be treated as a core component of the broader application security programme.

The objective is not simply to find vulnerabilities.

The objective is to identify how an attacker could abuse the API, understand the potential business impact, remove the underlying weakness, and continuously verify that the security boundary remains effective.