Many business owners only think about security after something goes wrong: someone logs into the admin panel and changes prices, user phone numbers are scraped in bulk, or strange links appear on the homepage. When they ask the developer, the answer is "we tested all the features." That's the problem—passing functional tests doesn't mean security is covered.
Most security vulnerabilities in website development aren't sophisticated attacks; they come from a few basic steps done wrong. Below, we go through the most common pitfalls in real projects, one by one.
1. Unauthorized Access: Being Logged In Doesn't Mean You Can See Everything
This is the most common issue in corporate websites and admin management systems. After user A logs in, they change the order ID in the address bar from 1001 to 1002 and can see user B's order. Developers often only hide buttons on the frontend, while the backend API doesn't verify "does this data belong to you."
The fix is simple: every API must verify whether the currently logged-in user has permission to operate on this data, not just check "is logged in." Role permissions must also be clearly separated—the menus and APIs accessible to regular employees and finance staff must be different.
Pitfall: Don't put permission checks on the frontend. Users can modify frontend code; the backend is the last line of defense. Before launch, have developers list every API that involves an ID and confirm ownership verification one by one.
2. Injection Vulnerabilities: String Concatenation Will Eventually Cause Problems
SQL injection is an old problem, but it's still happening today. A typical scenario is a search box or filter condition where developers directly concatenate user input into SQL statements. An attacker can input special characters to bypass conditions and dump an entire table.
The correct approach is to use parameterized queries or ORM bound parameters everywhere, never manual concatenation. The same applies to command execution and template injection—anywhere user input is treated as code, whitelist validation must be applied.
Pitfall: If you see string-concatenated SQL in the code, it can basically be rejected outright. Also, don't use root for database accounts—grant only the necessary permissions per business function, and the damage from an incident can be halved.
3. File Upload and Download: The Most Easily Overlooked Entry Point
Corporate websites need to upload product images and contract attachments; mini program development requires uploading avatars and ID photos. If the upload API only validates the file extension, an attacker can rename a script to .jpg, upload it, and then find a way to execute it.
Approach: Validate file types by actual content, not extension; prohibit script execution in upload directories; rename files before storage. Download APIs must also verify permissions—don't let someone change a path and download configuration files from the server.
Pitfall: Upload directories and website program directories must be separated. Many incidents happen because images and code are stored in the same executable directory.
4. API Authentication and Sensitive Information Exposure
In App development and mini program development, APIs are the main attack surface. There are three common problems: APIs lack rate limiting, so verification codes can be brute-forced indefinitely; response data includes fields that shouldn't be returned, such as ID numbers in a user list; error messages are too detailed, directly exposing database errors to the frontend.
Approach: Login, SMS, and payment APIs must have rate limiting and replay protection; response fields should be trimmed as needed; error messages should be unified. Don't log passwords or full phone numbers in plaintext either.
Pitfall: Don't sync test environment data directly to production. Many leaks happen because the test database contains real user data while the test environment has almost zero protection.
5. Launch Is Not the Finish Line: Security Testing Must Be Part of the Process
Many teams treat security as a one-time check and nobody manages it after launch. In reality, new feature releases, dependency upgrades, and server configuration changes can all reintroduce problems.
We recommend incorporating security testing into the release process: conduct an API and permission review with each major revision, regularly scan for dependency vulnerabilities, and perform penetration testing on critical systems annually. For projects like website redesigns, after updating pages, run through forms, search, and admin login—the cost is low and it blocks most low-level issues.
Pitfall: Don't just look at the number of findings in scan reports. High-risk items flagged by tools need manual confirmation of whether they can actually be exploited—false positives and false negatives are both common, and ultimately human judgment is needed for business logic vulnerabilities.
When to Consider MIC Studio
If your team doesn't have dedicated security staff, or you're about to do a website redesign, booking mini program, or admin management system and don't want to be firefighting after launch, you can hand off the security portion.
MIC Studio builds corporate websites, mini programs, and Apps, and also provides script development, website security testing, and reverse engineering testing. We prefer to go through permissions, uploads, and API issues against a checklist during the development phase, rather than patching things up after an incident.
Three Actionable Recommendations
1. Before launch, create an API inventory and confirm one by one whether login verification, data ownership verification, and rate limiting are all in place. If any is missing, log it as a to-do.
2. Review uploads and downloads separately as risk points, confirming that storage directories are not executable, file types are determined by content, and downloads go through permission checks.
3. Budget time and resources for security testing—run a check before each important release, and don't treat security as an optional post-launch item.