Many business owners first take security seriously only after their website has been injected with malware, their admin panel has been logged into by someone else, or their user data has been packaged and downloaded. By that point, investigating logs and patching vulnerabilities often costs far more than doing protection properly from the start.
To be honest, the common security vulnerabilities in web development are mostly not advanced techniques at all—they are basic tasks that were not done properly. Below, I will go through the most frequently encountered pitfalls in real-world practice, one by one.
1. Injection Vulnerabilities: SQL Injection and Command Injection
SQL injection is the most classic vulnerability. The cause is simple: the program concatenates user input directly into SQL statements. For example, entering a crafted string into a login field can bypass password verification, or even dump the entire user table.
Common practices and pitfalls to avoid:
- Use parameterized queries or an ORM; do not manually concatenate strings
- Assign database accounts based on least privilege; if it is read-only business, do not grant write permissions
- Disable detailed error reporting in production; error messages themselves are intelligence
- Validate input types, for example, allow only numbers for IDs
Command injection works the same way. Some scripting scenarios need to call system commands to process images or generate files. If the filename is concatenated directly into the command, an attacker can execute other instructions along with it. This type of issue is especially common in admin management systems.
2. Permissions and Privilege Escalation: Being Logged In Does Not Mean Having Permission
This is one of the most underestimated categories in corporate websites and backend systems. The user is indeed logged in, but accesses data they should not access.
There are two types:
- Horizontal privilege escalation: A regular user A changes the order number in the URL and sees user B's order
- Vertical privilege escalation: A regular user directly accesses administrator APIs, such as deleting users or exporting data
A specific scenario: in a booking-related mini program development project, the API is `/api/order/detail?id=1001`. The frontend only displays the user's own orders, but the backend does not verify whether this order belongs to the current user. As long as the id is changed to 1002, someone else's phone number and address can be seen.
Practices:
- Every API involving data must verify on the server side whether "the current user has permission to access this data"
- Do not rely on hiding buttons in the frontend for permission control
- Separate admin backend APIs from user-facing APIs, with independent authentication logic
3. File Upload and File Inclusion
File upload itself is not the problem. The problem is "whether it can be executed after upload."
Common pitfalls:
- Only validating the frontend file extension; changing it through request interception allows uploading PHP or JSP
- The upload directory has execution permissions, so uploading a script directly compromises the server
- Filenames are predictable, allowing attackers to enumerate and download files
Recommended practices:
- Validate file types on the server side, using a whitelist rather than a blacklist
- Disable script execution in the upload directory and allow only static access
- Rename files with random strings and do not retain the original path
- Perform secondary processing on image files to remove potentially embedded malicious content
4. API and Business Logic Vulnerabilities
Many vulnerabilities are not at the code level, but in business processes. For example:
- SMS verification codes have no rate limit and can be brute-forced
- Payment callbacks are not signature-verified, so a "paid" status can be forged
- Coupons can be claimed concurrently, allowing one person to claim a hundred
- The password recovery process can be bypassed, directly resetting someone else's password
This type of issue deserves special attention in App development and mini program development, because the API exposure surface is broader than that of traditional websites. Many people think "if the API cannot be seen in the App, it is secure," but once a packet capture tool is opened, the requests are completely clear.
Pitfalls to avoid:
- Add rate limiting and risk control to critical APIs
- Sensitive operations such as payments and refunds must be signature-verified and double-confirmed on the server side
- Business state transitions must be determined on the server side; do not trust state passed from the frontend
5. Dependency Components and Configuration Issues
Many corporate website problems are not caused by vulnerabilities in self-written code, but by outdated versions of open-source frameworks and plugins.
- Third-party CMS and website-building systems are not updated for long periods
- Default middleware configurations are not changed, such as weak admin passwords and default ports exposed externally
- Cloud server security groups are too open, directly exposing databases to the public internet
- Test environments, backup files, and .git directories are synchronized to production
The practices are very plain: regularly update dependencies, perform a configuration check before launch, close ports that should not be exposed externally, and delete unnecessary debugging files from production.
When It Is Appropriate to Engage MIC Studio
If your project falls into one of the following situations and your own team does not have the capacity for systematic investigation, engaging a professional team for a round of security testing will be more cost-effective:
- A corporate website has just been redesigned and launched, involving memberships, forms, and payments
- Mini program development or App development has entered the testing phase, with many APIs and complex logic
- The admin management system involves multiple roles and permissions, with high privilege escalation risk
- Reverse engineering testing is needed to assess the risk of APIs being called in bulk and data being scraped
- A security incident has already occurred, and the cause needs to be identified and hardening performed
MIC Studio's approach is to first sort out assets and APIs, then conduct testing across the directions of injection, permissions, uploads, logic, and configuration, and output a reproducible issue list and remediation recommendations, rather than only providing an incomprehensible scan report.
Conclusion: Three Things You Can Do Immediately
1. Perform a permission self-check before launch: List all APIs and ask one by one, "Can this be accessed without logging in?" and "Can another user's data be seen by changing the user ID?"
2. Manage input and output well: Validate all user input, parameterize all database operations, and prevent all error messages from leaking externally.
3. Treat security as an ongoing action: Regularly update dependencies, regularly check configurations, and perform a round of security testing before launching important versions. Do not wait until something goes wrong to fix it.
Security is not a one-time project, but part of the development process. Thinking it through earlier saves a lot of trouble later.