Establishing a Comprehensive Security Testing Process

1. Significance of Security Testing

When security incidents have not occurred, they may be overlooked, but once a production security issue arises it can become a "black swan" event for many companies. Platform security is an indispensable part of testing and requires continuous, long‑term attention.

2. Where to Start

Many companies lack dedicated security testers because the security technology stack is broad and talent is scarce. Small companies often consider outsourcing to third‑party security platforms as more cost‑effective. However, in agile environments it is not feasible to outsource every iteration, so testers must integrate security testing into the existing workflow. Common tools like AppScan or ZAP can be used, but many business‑specific security issues require manual testing. This article proposes a security testing execution path aligned with the overall software development lifecycle.

3. Building Our Security Testing Process

3.1 Requirement Phase

During requirement reviews, besides assessing feasibility and value, testers should adopt a "breaker" mindset to identify potential vulnerabilities. For example, if a merchant rewards users based on the number of likes, an attacker could repeatedly like via the API to overload the system and increase their chance of receiving gifts, highlighting the need for rate‑limiting controls.

3.2 Code Level

Static Code Scanning

Introduce static analysis tools such as SonarQube to automatically detect insecure code patterns.

Third‑Party Component Scanning

When developers import external dependencies, the source may be untrusted and could contain malicious code. Use tools like nsp for Node.js dependency scanning to ensure third‑party libraries are safe.

3.3 Data Masking

Focus on two aspects: encrypted storage of sensitive data (e.g., user passwords, merchant keys) and encrypted transmission (e.g., login credentials, SMS content). Verify encryption via database/file inspection and network capture tools such as browser DevTools, Fiddler, or Charles.

3.4 Cross‑Directory Permissions

In merchant management, sub‑accounts may have limited page access. Test whether a sub‑account can access unauthorized pages by directly entering URLs.

3.5 Cross‑Site Scripting (XSS)

Test for XSS by injecting JavaScript or HTML into input fields and observing whether the payload is escaped. Also try passing malicious scripts via URL parameters to see if they are executed.

3.6 SQL Injection

Construct malicious query parameters (e.g., appending "or 1=1" to an ID) to alter SQL logic and expose data. Use tools like sqlmap to automate injection testing.

3.7 Privilege Escalation

Verify that a user cannot operate on another user's data, such as ordering a member‑only product as a non‑member by manipulating request parameters captured with Fiddler.

3.8 File Upload/Download

Key concerns include limiting user disk space, validating file types (e.g., rejecting HTML uploads that could host XSS), and controlling download access to sensitive files such as payroll statements by preventing ID enumeration.

3.9 Server Port Scanning

For on‑premise deployments, scan open ports with tools like nmap and close any non‑essential services to reduce attack surface.

3.10 Business‑Specific Test Cases

General rules can be tailored to specific features; for login/registration, test password strength, captcha effectiveness, and rate‑limiting for SMS verification to mitigate abuse and cost leakage.

4. Conclusion

Security is an essential component of quality assurance. Testers should embed security thinking throughout the software development lifecycle, starting from the basics, to ensure security quality is built‑in. Collaboration and sharing of security testing practices are encouraged.