Web, API and Mobile App Penetration Testing in the Philippines

Philippine software companies are increasingly building products that depend on web applications, APIs, mobile applications, cloud platforms, and third party services. These technologies allow businesses to serve customers across the Philippines and international markets, but they also create multiple application attack surfaces.

For software companies selling to enterprises, financial organizations, healthcare providers, technology companies, and international customers, application security can become an important part of customer security reviews and vendor evaluations.

Penetration testing provides a practical way to examine applications from an attacker's perspective. Instead of focusing only on automated vulnerability scanning, penetration testing can examine authentication, authorization, business logic, input handling, session management, data protection, and application-specific attack paths.

The appropriate testing scope depends on how an application is built and used. A company with a customer-facing website may require extensive web application testing. A SaaS platform built around APIs may require substantial API testing. A company offering Android and iOS applications may require mobile application penetration testing in addition to backend API testing.

Understanding these differences allows Philippine software companies to establish a penetration testing scope that reflects their actual technology environment.

Identify Application Security Risks. Evaluate web, API, mobile, network, and other environments through penetration testing. Explore VAPT Services.

Growing Dependence on Web, API, and Mobile Applications

Modern software products rarely operate through a single interface.

A SaaS platform may have a browser-based interface, REST or GraphQL APIs, mobile applications, administrative portals, cloud services, and integrations with external platforms. Each component can introduce different security considerations.

Web applications typically expose functionality through browsers. APIs expose application functionality and data through programmatic endpoints. Mobile applications introduce device-side components, local storage, application binaries, authentication flows, and communication with backend services.

This means that securing one application component does not automatically establish security across the entire application ecosystem.

Increasing Application-Level Cybersecurity Risks

Application vulnerabilities can affect confidentiality, integrity, and availability.

Examples include unauthorized access to another user's account, exposure of sensitive records, manipulation of transactions, insecure authentication mechanisms, injection vulnerabilities, insufficient access controls, insecure data storage, and weaknesses in business workflows.

OWASP's 2021 Top 10 identifies risks such as Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, and Identification and Authentication Failures among the major web application security risks.

API environments have their own risk categories. The OWASP API Security Top 10 2023 includes Broken Object Level Authorization, Broken Authentication, Broken Function Level Authorization, Unrestricted Resource Consumption, and Unsafe Consumption of APIs.

Why Penetration Testing Matters Before Software Deployment

Security testing before a major release can identify weaknesses while application architecture, authentication flows, access controls, and business processes are still being evaluated by the development and security teams.

Testing before deployment is particularly relevant when an application:

• Processes sensitive customer information
• Handles financial transactions
• Provides administrative functionality
• Exposes public APIs
• Uses third party integrations
• Contains different user roles
• Provides access to confidential business information
• Is being launched for enterprise customers

Testing should not be limited to a single point in the software lifecycle. Major changes to authentication, authorization, APIs, payment workflows, or data processing can introduce new security risks.

Security Expectations from Enterprise and International Customers

Enterprise customers frequently ask software vendors about application security practices during vendor security reviews.

Depending on the customer and industry, questions may cover penetration testing, vulnerability management, authentication controls, encryption, access management, incident response, security monitoring, and security testing evidence.

For Philippine software companies serving customers in other countries, a recent penetration testing report can therefore become part of the broader security evidence shared during customer due diligence.

The exact requirements differ by customer, contract, industry, and regulatory environment. Penetration testing does not replace other security controls or certifications, but it can provide evidence about the security of the tested application at a particular point in time.

Web Application Penetration Testing

What Is Web Application Penetration Testing?

Web application penetration testing examines a web application's externally accessible functionality and security controls from an attacker's perspective.

Testing can include public pages, authenticated functionality, administrative interfaces, user roles, session handling, input processing, business workflows, APIs exposed through the web application, and other application components within the agreed scope.

The OWASP Web Security Testing Guide, commonly referred to as WSTG, provides a structured collection of techniques covering areas such as authentication, authorization, session management, input validation, business logic, cryptography, and error handling. OWASP describes WSTG as a practical framework rather than a rigid checklist or compliance standard.

Common Web Application Vulnerabilities

Web application vulnerabilities can vary considerably depending on the application's architecture and functionality.

Common areas examined during web application penetration testing include:

• Broken access control
• Authentication weaknesses
• Session management issues
• Injection vulnerabilities
• Cross-site scripting
• Security misconfiguration
• Insecure handling of sensitive information
• Server-side request forgery
• Vulnerable or outdated components
• Business logic weaknesses
• Information disclosure

The presence or absence of a particular vulnerability cannot be determined solely from the application's technology stack. Testing needs to consider the application's actual functionality and threat model.

OWASP Top 10 Testing for Web Applications

The OWASP Top 10:2021 is an awareness document covering major web application security risks. Its categories include Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, and Server-Side Request Forgery.

For penetration testing, these categories can provide a useful starting point. However, testing should not stop at checking whether an application contains items from a predefined list.

Application-specific functionality may introduce risks that are not obvious from a generic vulnerability category.

Authentication and Session Management Testing

Authentication testing examines how an application verifies user identity and whether authentication controls can be bypassed.

Testing may consider:

• Login mechanisms
• Password policies
• Multi-factor authentication
• Account recovery
• Session tokens
• Session expiration
• Logout behavior
• Authentication bypass attempts
• Token handling
• Brute-force protection

OWASP WSTG specifically includes testing techniques for authentication mechanisms and authentication bypass scenarios.

Authorization and Access Control Testing

Authentication answers the question of who a user is. Authorization determines what that user is permitted to access or perform.

Testing can involve multiple roles and privilege levels to determine whether users can access functions or information outside their authorized permissions.

Examples include testing whether:

• A standard user can access administrative functionality
• One customer can access another customer's records
• A lower-privileged account can perform privileged actions
• Direct object references expose unauthorized information
• Restricted functions remain accessible through alternate requests

Broken access control remains the first category in the OWASP Top 10:2021.

Business Logic Vulnerability Testing

Business logic vulnerabilities occur when an application's workflow can be manipulated in ways that violate intended business rules.

For example, an application may require a specific sequence of actions before completing a transaction. A tester may examine whether that sequence can be bypassed, repeated, reversed, or manipulated.

OWASP notes that business logic vulnerabilities are often application-specific and may not be identified through automated vulnerability scanning alone.

This makes business logic testing particularly relevant for applications involving payments, subscriptions, approvals, account changes, order processing, discounts, quotas, or other important workflows.

Input Validation and Injection Testing

Applications frequently receive input through forms, URL parameters, API requests, file uploads, headers, and other interfaces.

Penetration testing can examine how this input is processed and whether malicious or unexpected input can alter application behavior.

Testing may include SQL injection, command injection, cross-site scripting, server-side template injection, and other input-related weaknesses depending on the application's architecture.

API Penetration Testing

What Is API Penetration Testing?

API penetration testing examines the security of application programming interfaces that expose application functionality or data.

APIs are frequently used by web applications, mobile applications, SaaS platforms, partner systems, and internal services. OWASP notes that APIs can expose application logic and sensitive information, making API-specific security testing important.

API testing can examine authentication, authorization, object access, input validation, resource consumption, business workflows, API inventories, configuration, and third party integrations.

Common API Security Vulnerabilities

Common API security risks include:

• Broken Object Level Authorization
• Broken Authentication
• Broken Object Property Level Authorization
• Unrestricted Resource Consumption
• Broken Function Level Authorization
• Unrestricted Access to Sensitive Business Flows
• Server-Side Request Forgery
• Security Misconfiguration
• Improper Inventory Management
• Unsafe Consumption of APIs

These are the ten categories in the OWASP API Security Top 10 2023.

OWASP API Security Top 10 Testing

The OWASP API Security Top 10 2023 provides an API-specific set of security risks. It should be considered alongside application architecture, business requirements, authentication mechanisms, data flows, and actual API functionality.

For example, an API may expose an object identifier in a request. Testing can determine whether changing that identifier allows one authenticated user to access another user's object.

Likewise, an API may expose administrative functions that require a particular privilege level. Testing can examine whether those functions remain accessible to lower-privileged users.

OWASP itself states that the API Security Top 10 is an awareness document and that application-specific technical details can significantly affect the actual risk associated with an API.

API Authentication Testing

API authentication testing examines how APIs verify the identity of clients and users.

Depending on the architecture, testing may examine:

• Access tokens
• JWT handling
• OAuth flows
• API keys
• Session tokens
• Token expiration
• Authentication bypass
• Credential exposure
• Token reuse
• Authentication error handling

Broken Authentication is listed as API2:2023 in the OWASP API Security Top 10.

API Authorization Testing

API authorization testing determines whether authenticated users can perform only the actions and access only the objects permitted to them.

Object-level authorization is particularly important for APIs because endpoints often process identifiers representing customer accounts, orders, files, records, or other resources.

OWASP identifies Broken Object Level Authorization as API1:2023 and Broken Function Level Authorization as API5:2023.

API Input Validation and Injection Testing

API requests can contain parameters, JSON objects, XML data, headers, file content, and other user-controlled input.

Testing can examine whether the API validates input correctly and whether unexpected data can cause unauthorized behavior, injection, data exposure, or application errors.

The exact techniques depend on the API technology, backend architecture, data stores, and connected services.

Rate Limiting and Business Logic Testing

APIs may expose resource-intensive operations or sensitive business functions.

Testing can examine whether an API adequately restricts repeated requests and whether sensitive workflows can be abused through unusual request sequences.

The OWASP API Security Top 10 includes Unrestricted Resource Consumption as API4:2023 and Unrestricted Access to Sensitive Business Flows as API6:2023.

Mobile Application Penetration Testing

What Is Mobile Application Penetration Testing?

Mobile application penetration testing examines the security of Android and iOS applications and their interaction with backend services.

Testing may cover the mobile application binary, local data storage, authentication, session management, network communication, cryptography, application configuration, runtime behavior, and backend APIs within the agreed scope.

A mobile application should not automatically be considered secure simply because its backend API has been tested. The mobile application itself can contain client-side weaknesses that require separate examination.

Common Mobile Application Vulnerabilities

Mobile application security risks can include:

• Improper credential usage
• Insecure authentication and authorization
• Insufficient input and output validation
• Insecure communication
• Inadequate privacy controls
• Insufficient binary protections
• Security misconfiguration
• Insecure data storage
• Insufficient cryptography
• Supply chain security weaknesses

The OWASP Mobile Top 10 2024 includes these categories as part of its current mobile application risk list.

OWASP Mobile Top 10 Testing

The OWASP Mobile Top 10 2024 identifies ten mobile application risk categories, including Improper Credential Usage, Inadequate Supply Chain Security, Insecure Authentication and Authorization, Insecure Communication, Insecure Data Storage, and Insufficient Cryptography.

These categories provide a starting point for mobile security testing. They should be considered alongside the application's architecture, backend services, data processing, authentication model, and business functionality.

Mobile Authentication and Session Testing

Mobile authentication testing examines how the application handles login, tokens, sessions, password recovery, multi-factor authentication, and account state.

Testing can also examine whether authentication credentials or tokens are unnecessarily exposed through local storage, logs, application behavior, or network traffic.

The backend authentication system and the mobile application's handling of authentication information should be considered together.

Insecure Data Storage Testing

Mobile applications may store information locally for performance, offline functionality, or user convenience.

Testing can examine whether sensitive information is stored in inappropriate locations or protected inadequately.

Potential areas include:

• Authentication tokens
• User credentials
• Personal information
• Application configuration
• Cached data
• Local databases
• Logs
• Temporary files

The appropriate controls depend on the type and sensitivity of information being stored.

Network Communication and Encryption Testing

Mobile applications frequently exchange information with backend APIs and external services.

Testing can examine whether sensitive information is transmitted securely, whether certificate validation is appropriately configured, and whether insecure communication paths expose application data.

OWASP lists Insecure Communication as M5 in its Mobile Top 10 2024 and Insufficient Cryptography as M10.

Reverse Engineering and Application Tampering Testing

Mobile application binaries can be examined to understand how applications behave and whether security-sensitive information or functionality can be extracted or manipulated.

Testing may consider binary protections, exposed secrets, insecure application logic, tampering resistance, and runtime behavior.

OWASP identifies Insufficient Binary Protections as M7 in the Mobile Top 10 2024.

Web Application vs API vs Mobile App Penetration Testing

Differences in Attack Surface

The attack surface varies according to the application type.

A web application primarily exposes browser-accessible functionality and server-side application logic.

An API exposes endpoints, objects, functions, data structures, and business operations that can be accessed programmatically.

A mobile application introduces a client-side environment that exists on a user's device while also communicating with backend services.

Many modern products contain all three. In those cases, treating each component as a completely separate security environment may overlook relationships between them.

Differences in Common Vulnerabilities

Web applications commonly require examination of access control, authentication, injection, session management, security configuration, and business logic.

APIs require particular attention to object-level authorization, function-level authorization, authentication, resource consumption, API inventory, sensitive business flows, and third party API consumption.

Mobile applications require additional attention to local storage, binary protections, mobile authentication, secure communication, privacy controls, and cryptographic handling.

There is overlap between the three areas, but the attack surface and testing techniques are not identical.

Differences in Testing Methodology

Web application testing may focus heavily on browser requests, application workflows, session handling, roles, parameters, and server-side behavior.

API penetration testing often involves examining endpoints, request methods, object identifiers, tokens, schemas, roles, response data, rate controls, and API workflows.

Mobile application testing combines application analysis with runtime testing. It may involve examining the mobile package, application behavior, local storage, network traffic, device interactions, and backend communication.

Differences in Security Objectives

The security objective should reflect what the application is designed to protect.

For a customer portal, the priority may include account security and protection of customer records.

For an API platform, authorization of objects and functions may be especially important.

For a mobile banking or financial application, secure authentication, transaction integrity, local data protection, and secure communications may receive significant attention.

For a SaaS platform, tenant isolation and authorization across customer environments can be critical.

When Each Type of Penetration Testing Is Required

The testing type should correspond to the technology exposed to users and other systems.

A company with only a public web application may initially focus on web application penetration testing.

A company whose core product is API-driven may require dedicated API penetration testing.

A company with Android or iOS applications should consider mobile application penetration testing alongside backend testing.

Organizations operating multiple application channels may require a combined scope covering web, API, and mobile components.

Which Penetration Testing Should Philippine Software Companies Prioritize?

There is no single testing type that applies equally to every Philippine software company. The appropriate priority depends on the technology, users, data, business model, and customer requirements.

Companies With Customer-Facing Web Applications

Companies operating customer portals, SaaS dashboards, ecommerce platforms, booking systems, employee portals, or other browser-based applications should consider web application penetration testing.

Testing should include important authenticated and unauthenticated functionality, user roles, sensitive workflows, and application-specific business processes.

Companies With API-Driven Platforms

Companies whose products depend heavily on APIs should consider dedicated API penetration testing.

This is particularly relevant when APIs expose customer records, transactions, account information, administrative functions, or other sensitive application functionality.

The OWASP API Security Top 10 provides a useful reference for identifying API-specific security risks.

Companies With iOS or Android Applications

Mobile applications introduce risks that may not be visible from backend testing alone.

A mobile application penetration test can examine local data, authentication handling, application binaries, network communication, cryptography, and other mobile-specific areas.

Companies Operating Multiple Application Channels

A company offering a web platform, public APIs, and mobile applications may require a broader VAPT scope.

For example, a mobile application may use an API to retrieve customer information, while the same API may also serve the web platform.

Testing these components together can provide a clearer picture of how vulnerabilities in one component may affect another.

Companies Handling Sensitive Customer or Financial Data

Organizations handling personal, financial, healthcare, authentication, payment, or confidential business data may need a more extensive application testing scope.

The scope should consider where sensitive data enters the system, how it is processed, where it is stored, and which users or systems can access it.

How to Determine the Right Application Penetration Testing Scope

A well-defined scope prevents important application components from being unintentionally excluded.

Identify All Public-Facing Applications

Start by identifying websites, customer portals, administrative portals, public applications, mobile applications, and other externally accessible systems.

Include staging or test environments when they contain production-like data or functionality and are within the agreed testing scope.

Map APIs and Backend Services

Identify APIs used by web applications, mobile applications, partners, and third party systems.

API inventories should account for different versions and endpoints. OWASP specifically identifies Improper Inventory Management as an API security risk because organizations can expose outdated or undocumented API versions.

Identify Mobile Application Components

For mobile applications, identify the Android and iOS packages, backend APIs, authentication services, third party SDKs, local storage mechanisms, and other components relevant to the application.

Define User Roles and Privileges

Application security testing should account for different levels of access.

Typical roles might include:

• Standard users
• Premium users
• Managers
• Administrators
• Support personnel
• Partner users
• API clients

Testing across these roles can reveal authorization weaknesses that may not appear when testing with only one account.

Include Business-Critical Workflows

Important workflows should be clearly identified before testing.

Examples include:

• Account registration
• Login and password recovery
• Payment processing
• Order creation
• Subscription changes
• File uploads
• Approval workflows
• Account ownership changes
• Financial transactions
• Administrative operations

Business logic testing is particularly relevant because some weaknesses depend on how an application's workflow operates rather than on a conventional technical vulnerability.

Consider Third-Party Integrations and Dependencies

Applications frequently exchange data with payment providers, identity platforms, cloud services, analytics platforms, communication services, and other third party systems.

The testing scope should identify these dependencies and clarify which components are authorized for testing.

OWASP's API Security Top 10 includes Unsafe Consumption of APIs as API10:2023, highlighting risks associated with trusting or interacting with external APIs.

Key Penetration Testing Areas Across Web, API, and Mobile Applications

Authentication Testing

Authentication testing examines whether users and systems can be reliably identified and whether authentication controls can be bypassed.

This can include passwords, multi-factor authentication, tokens, session identifiers, password recovery, and authentication state management.

Authorization and Access Control Testing

Authorization testing examines whether users can access only the resources and functions permitted by their role.

This becomes particularly important in multi-tenant SaaS platforms, enterprise portals, APIs, and applications containing multiple privilege levels.

Business Logic Testing

Business logic testing examines whether application workflows can be manipulated to produce outcomes that should not be possible.

Technical security controls may appear correct while a specific business workflow still permits an unintended action.

Session Management Testing

Session testing examines how applications create, maintain, expire, invalidate, and protect sessions.

Testing may cover session fixation, session expiration, logout behavior, token reuse, concurrent sessions, and session handling after account or privilege changes.

Input Validation and Injection Testing

Input validation testing examines whether applications safely process data supplied by users or external systems.

Depending on the technology, testing may cover SQL injection, cross-site scripting, command injection, template injection, XML-related attacks, and other injection categories.

Data Protection and Encryption Testing

Testing can examine how sensitive information is stored and transmitted.

For mobile applications, this may include local storage and network communication. For web applications and APIs, it may include sensitive information in requests, responses, cookies, tokens, logs, or other application components.

Error Handling and Information Disclosure Testing

Application errors can sometimes expose technical information that should not be available to users.

Testing may examine error messages, stack traces, debug responses, server headers, API responses, and other information that could reveal internal application details.

How OWASP Helps Define Application Penetration Testing Priorities

OWASP resources provide widely used security references for web, API, and mobile application testing.

They should be treated as starting points rather than complete definitions of every application's security requirements.

OWASP Top 10 for Web Applications

The OWASP Top 10:2021 identifies ten major web application security risks, including Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, and Identification and Authentication Failures.

These categories can be used to structure web application security testing while considering application-specific functionality.

OWASP API Security Top 10

The OWASP API Security Top 10 2023 focuses specifically on API security risks.

Its categories include Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, and Improper Inventory Management.

OWASP Mobile Top 10

The OWASP Mobile Top 10 2024 addresses mobile-specific risks such as Improper Credential Usage, Insecure Authentication and Authorization, Insecure Communication, Inadequate Privacy Controls, Insufficient Binary Protections, Insecure Data Storage, and Insufficient Cryptography.

Using OWASP Guidance to Define Testing Scope

OWASP resources can provide a common security vocabulary for defining application penetration testing objectives.

For example, a security team can use the OWASP Top 10 for web applications, OWASP API Security Top 10 for APIs, and OWASP Mobile Top 10 for mobile applications as references when establishing testing areas.

The OWASP WSTG also provides detailed testing techniques across areas such as identity management, authentication, authorization, session management, input validation, and business logic.

Why OWASP Categories Should Not Replace Application-Specific Testing

A Top 10 list cannot represent every vulnerability that may exist in a particular application.

OWASP itself describes its Top 10 resources as awareness material rather than a complete risk analysis for an individual organization. The API Security Top 10 also notes that application-specific technical details can significantly affect risk.

A banking application, healthcare platform, ecommerce website, and internal enterprise portal may all use similar technologies while having very different business risks.

Application penetration testing should therefore consider the actual functionality, architecture, data, user roles, integrations, and business workflows.

When Should Philippine Software Companies Conduct Application Penetration Testing?

Before Launching a New Application

Testing before public release can identify security weaknesses before customers begin using the application.

For new software products, the scope should consider public functionality, authentication, authorization, APIs, business workflows, sensitive data, and administrative interfaces.

After Major Application Changes

Significant changes to authentication, authorization, payment functionality, APIs, user roles, data processing, or application architecture can change the application's security profile.

A new penetration test or targeted testing may therefore be considered after substantial changes.

Before Enterprise Customer Onboarding

Enterprise customers may request security testing evidence before onboarding a software vendor.

Having a recent penetration testing report can provide relevant security information for customer security questionnaires and vendor assessments, subject to the customer's specific requirements.

Before Regulatory or Security Assessments

Certain industries and contracts may have specific security testing expectations.

The exact requirement depends on the applicable regulation, contract, industry, and customer. Penetration testing should therefore be mapped to the actual requirement rather than assumed to satisfy every regulatory obligation.

As Part of a Recurring Security Testing Program

Application security changes over time as applications receive new releases, integrations, dependencies, features, and infrastructure changes.

A recurring penetration testing program can provide periodic visibility into the security of important application assets.

The appropriate frequency depends on factors such as application risk, release cycles, customer requirements, regulatory expectations, and major architectural changes.

Strengthen Your Application Security. Identify vulnerabilities across web, API, mobile, network, and other technology environments.. Explore VAPT Services.

Application Penetration Testing for Philippine Software Companies Serving Global Customers

Philippine software companies increasingly serve customers outside the domestic market. When software products are sold internationally, application security can become an important component of enterprise procurement and vendor security reviews.

Meeting Enterprise Customer Security Expectations

International customers may request evidence of penetration testing, vulnerability management, access control, authentication, encryption, and other security measures.

Requirements vary between organizations. A penetration testing report can provide technical evidence about vulnerabilities identified within the agreed scope and testing period.

Supporting Vendor Security Reviews

Enterprise procurement teams may ask software vendors to complete security questionnaires or provide independent security evidence.

A clearly scoped penetration test can provide information that complements questionnaires, security policies, certifications, and other assurance materials.

Protecting Customer and Business Data

Software companies may process customer records, credentials, financial information, intellectual property, business information, or personal data.

Application security testing can examine controls intended to prevent unauthorized access, manipulation, or exposure of this information.

Demonstrating Security Testing Evidence

For software companies serving global customers, the ability to provide a recent security testing report may be relevant during vendor reviews.

The report should clearly state the testing scope, application or environment tested, testing period, methodology or reference framework, identified findings, and relevant remediation status where applicable.

Read More:
Penetration Testing VAPT Frequency for Philippine BPOs