As long as your website, mini program, or App provides services externally, it will inevitably be scanned, probed, and attacked. The only difference is whether it has been discovered yet. Many teams put all their energy into feature development and launch speed, delaying security testing again and again. As a result, a single unauthorized API or upload point can cause the entire system to fall. In its long-term security testing and reverse engineering testing services, MIC Studio has repeatedly seen the same pattern: what truly breaks through a system is often not highly sophisticated technology, but several types of overlooked old problems. This article explains the most common vulnerabilities in website security testing in depth and provides hardening recommendations that can be followed directly.
1. First, Clarify the Goals and Boundaries of Security Testing
Security testing is not about buying a scanner, running it once, and calling it done. It needs to answer three questions: Where can an attacker enter from? How much can they obtain after getting in? How much damage can they cause after obtaining it?
By testing method, there are usually three categories:
- Black-box testing: Fully simulates an external attacker without access to source code or accounts, and is closest to a real attack scenario;
- White-box testing: Combines source code auditing and can discover deep logic issues that black-box testing cannot find;
- Gray-box testing: Uses partial accounts or API documentation, is the most efficient, and is suitable for projects with frequent iterations.
For most small and medium-sized projects, prioritizing the API layer and permission layer offers the best value. This is because these two areas have the most frequent problems and the most severe consequences - data leaks, unauthorized operations, and backend takeover basically all start here.
2. SQL Injection: An Old Problem That Remains the Number One Killer
SQL injection has existed for more than twenty years, but it is still a frequent presence on various vulnerability lists. The reason is simple: as long as there is one place where SQL is concatenated, it may be exploited.
Typical scenarios:
- The login API uses string concatenation to query users, and entering `' or '1'='1` directly bypasses the password;
- The sorting fields and search conditions of list queries are directly concatenated into SQL, leading to error-based injection or time-based blind injection;
- Some legacy systems use ORM but concatenate native SQL, which also carries risk.
Hardening recommendations:
- Fully use parameterized queries (prepared statements), and prohibit string-concatenated SQL at the code standard level;
- For positions that cannot be parameterized, such as sorting fields and table names, use whitelist validation and allow only preset values;
- Database accounts should follow the principle of least privilege, and business accounts should not be granted high-risk permissions such as DROP, FILE, and GRANT;
- Disable detailed error output in the production environment to avoid leaking table structures and database versions;
- Introduce WAF as a supplementary defense line, but do not treat it as the only protection.
3. XSS Cross-Site Scripting: The Longest-Lurking Injection
The essence of XSS is that user input is executed as code. Stored XSS is the most harmful because it remains on the page for a long time and affects every visitor.
Typical scenarios:
- Comment sections, nicknames, and personal signatures are directly output to the page;
- Rich text editors allow `