November 9, 2026
November 9, 2026
Your web application is open to the world around the clock. It might be a customer portal, a booking system, an online shop or an internal tool your staff use from home. Either way, every login form, search box and file upload is a door someone could try. Most of the attacks aimed at these doors aren't sophisticated. They work because something basic was missed. This guide walks through the most common web application threats in plain language and explains what you can do to prevent them.
The most common web application threats at a glance
Web application security is the practice of protecting websites, web portals and online services from attacks that target the application itself: its code, its logic, its data and the way users log in. It covers everything from how the software is designed and written to how it's configured, hosted, tested and monitored after launch.
It's different from network security, which protects the infrastructure around the application, such as firewalls and servers. A firewall can block a lot of unwanted traffic, but it can't stop someone who logs in with a stolen password and then reads other customers' orders because the application never checked whether they were allowed to. That kind of flaw lives inside the application, so it has to be fixed there.
Responsibility is usually shared. Your development team or partner is responsible for secure code and configuration. Your hosting or cloud provider looks after the underlying infrastructure. And your own business decides who gets access, which data is collected and how quickly security updates are approved. Gaps tend to appear where those responsibilities meet.
Web applications sit on the public internet, they often hold personal or payment data, and they're built from many moving parts: your own code, open-source libraries, plugins, APIs and cloud services. Each part can introduce a weakness.
Attackers also don't need to pick you specifically. Automated tools scan large parts of the internet every day, looking for known vulnerabilities in common software. If your application runs an outdated plugin with a published flaw, it can be found and attacked within days, regardless of the size of your business.
The 2017 breach at US credit bureau Equifax is the classic example. Attackers exploited a known vulnerability in Apache Struts, a widely used open-source web framework, for which a fix had already been released. The personal data of around 147 million people was exposed. The lesson for any business is simple: many serious incidents don't involve new or clever techniques, just a known problem that wasn't fixed in time.
The OWASP Top 10, published by the Open Worldwide Application Security Project, is the most widely used reference for web application risks. Its latest edition, the OWASP Top 10:2025, lists broken access control, security misconfiguration and software supply chain failures as the top three. The threats below follow the same ideas, explained for business owners and managers rather than for security specialists.
This is the most common serious flaw in web applications, and it's easy to understand. Access control decides who can see and do what. When it's broken, users can reach data or functions they shouldn't.
A typical example: a customer views their invoice at an address ending in /invoice/10452. They change the number to 10453 and see another customer's invoice. The application checked that they were logged in, but never checked whether that invoice belonged to them. Other versions of the same problem include ordinary users opening admin pages by guessing the address, or changing a hidden field to give themselves a discount or a higher role.
Prevention comes down to one rule: check permissions on the server for every request, every time, and deny access by default. Hiding a button in the interface isn't protection, because the request can still be sent directly.
Many breaches start with settings rather than code. Common examples include default admin passwords that were never changed, test pages left online after launch, cloud storage buckets set to public, and error messages that show technical details such as database names or file paths.
The fix is mostly discipline. Use a standard, hardened configuration for every environment, remove anything that isn't needed, and review settings as part of every release. Automated configuration checks help, especially when your application runs in the cloud. Our article on cloud security solutions covers this side in more detail.
Modern web applications rely heavily on open-source libraries, frameworks and plugins. That's normal and saves a lot of time, but it means a flaw in someone else's code can become a flaw in yours. The Equifax breach is one example. Every popular content management system and e-commerce platform has seen similar issues with outdated plugins.
OWASP's 2025 list widens this into "software supply chain failures", which also covers compromised packages, build tools and update channels. In practice, protection means:
Regular system maintenance and updates are the unglamorous part of security, and often the part that matters most.
Injection happens when an application takes something a user typed and treats it as a command. With SQL injection, an attacker types database commands into a form field or URL, and the application runs them, potentially exposing or deleting data. In 2023, a SQL injection flaw in the MOVEit Transfer file-sharing software was exploited by a ransomware group to steal data from a large number of organisations worldwide.
Cross-site scripting, or XSS, is a related problem. An attacker gets their own script into a page, for example through a comment or a product review, and that script then runs in other users' browsers. It can steal session information or redirect people to fake login pages.
The good news is that injection is well understood and preventable. Developers should use parameterised queries instead of building database commands from user input, validate input on the server, encode output before displaying it, and use modern frameworks that handle much of this automatically.
Login pages are attacked constantly. One of the most common methods is credential stuffing: attackers take usernames and passwords leaked from other websites and try them on yours, knowing that many people reuse passwords. Other problems include weak password rules, no limit on login attempts, and session tokens that stay valid for too long.
Strong authentication usually includes:
Personal details, payment information, health data and business records need extra care. Problems arise when data is sent without encryption, stored in plain text, kept longer than needed, or visible in logs and backups that aren't protected.
Use HTTPS everywhere, encrypt sensitive data in storage, and avoid collecting data you don't really need. Less data means less to protect. Beyond the technical risk, there are legal ones: in Singapore and Malaysia, data protection laws require organisations to take reasonable security measures for the personal data they hold.
Some attacks run for weeks because nobody notices. If your application doesn't record important events, such as failed logins, permission errors and changes to admin settings, or if those records are never reviewed, you lose the chance to stop an attack early.
Log security-relevant events, keep the logs somewhere attackers can't easily change them, and set up alerts that reach a person who will act on them. Monitoring and proactive support is often the most practical way for smaller companies to get this coverage without a full security team.
Security works best when it's part of every stage of a project rather than a check at the end. Here's what that looks like in practice.
While designing and building
Think about security from the first requirements. Decide who can access what, which data is sensitive, and what could go wrong if someone misuses a feature. During development, follow secure coding practices, use well-maintained frameworks, review code with security in mind, and keep secrets such as passwords and API keys out of the source code.
Before launch
Test the application for vulnerabilities, not just for features. Run automated security scans, fix the issues they find, and for applications that handle sensitive data or payments, arrange a penetration test by a qualified specialist. Remove test accounts, sample data and debug settings before going live. Our guide to building an effective QA and testing strategy explains where security testing fits.
After launch
This is where many businesses relax too early. Keep components and servers patched, monitor logs and alerts, back up data and test the restores, and review access rights when staff join or leave. A web application firewall (WAF) can block many common attacks before they reach your application, although it's an extra layer rather than a replacement for secure code. Good cloud hosting setups usually include a WAF and DDoS protection as options.
For SMEs in Singapore, the Cyber Security Agency's Cyber Essentials mark is a useful starting point for basic security controls across the business, including the systems your web application depends on.
"Security testing" covers several quite different activities. Knowing the difference helps you ask for the right thing and compare quotes properly.
Automated tools are fast and cheap to run often, but they miss logic problems such as the invoice example above. Penetration testers find those, but cost more and only give you a snapshot in time. Most businesses benefit from a mix: automated checks all the time, and manual testing at key moments.
If an external team builds or maintains your web application, security is a fair topic to raise early. A few questions will tell you a lot about how seriously they take it.
Ask how they handle access control and authentication in their projects, and whether they follow the OWASP guidelines. Find out what security testing is included in the price, and what would cost extra. Check how they manage third-party components and how quickly they apply security patches after launch. Ask who has access to your production systems and data, and how that access is controlled and logged. And ask what happens if they discover a security incident: who they tell, how fast, and what they do next.
A partner who answers these questions clearly, with examples, is usually one who has dealt with them before. Our article on data security in software development outsourcing goes deeper into what to check when working with an outsourced team.
Serdao has been building and supporting business software for more than 18 years, with development and support teams in Ho Chi Minh City, Vietnam, and project management from our headquarters in France. Security is part of how we design, build and run applications, not a separate add-on.
Depending on your needs, we can help with:
If you'd like to understand where your current application stands, our IT security management guide is a good place to start. You can also explore our software development services or contact our team to talk about a review of your application.
Conclusion
Most web application attacks exploit a short list of well-known weaknesses: access checks that were skipped, settings that were never changed, plugins that weren't updated, input that wasn't validated, and alerts nobody read. None of these require an enormous budget to fix. They require attention at every stage, from design to daily operations.
If you only take three actions after reading this, make them these: check that your application enforces permissions on the server, put a regular patching routine in place, and make sure someone is actually watching the security alerts.
1. What is the most common web application vulnerability?
Broken access control is ranked first in the OWASP Top 10:2025. It happens when users can view or change data or functions they shouldn't have access to, for example by changing an ID in a web address.
2. What is the OWASP Top 10?
It's a regularly updated list of the most critical security risks to web applications, published by the Open Worldwide Application Security Project. Developers and security teams use it as a common reference when designing, building and testing applications.
3. Does a web application firewall make my application secure?
A WAF blocks many common attacks and is a useful extra layer, but it doesn't replace secure code. Flaws such as broken access control often look like normal traffic, so a firewall can't reliably detect them.
4. How often should a web application be tested for security?
Automated scans should run continuously or before every release. A manual penetration test is usually recommended before launching an application that handles sensitive data, after major changes, and then periodically, often once a year.
5. Are small business websites really at risk?
Yes. Many attacks are automated and target known vulnerabilities in common software, not specific companies. A small site running an outdated plugin can be found and attacked just as easily as a large one.
6. What should I do if I think my web application has been hacked?
Contact your development or support team immediately, preserve logs and evidence, change administrator passwords, and assess what data may be affected. Depending on the data involved, you may also have legal obligations to notify the authorities or affected customers.
7. Who is responsible for web application security, the developer or the business?
Both. The development team is responsible for secure code and configuration, the hosting provider for the infrastructure, and the business for decisions such as who has access, what data is collected and how quickly updates are approved. Clear agreements help avoid gaps.