Web Application Security Checklist for Small and Mid-Sized Businesses

Small and mid-sized businesses are attractive targets precisely because attackers assume they have weaker defenses than large enterprises. A customer portal, an internal tool or an e-commerce site can expose customer data, payment details and business operations if basic security practices are missing.

The good news: most successful attacks exploit well-known weaknesses such as stolen passwords, outdated software, missing access checks and misconfigured servers. You do not need an enterprise security budget to close them. This web application security checklist covers the measures that matter most, organized so you can review your own applications or discuss them with your development partner.

How to use this checklist

Go through each section and mark items as done, partially done or missing. Start with the items marked essential: they address the most common causes of breaches. If you rely on an external development team, ask them to walk you through how each item is handled. A good team will answer confidently and specifically.

1. Access and authentication

• Essential: Multi-factor authentication (MFA) for all administrator and staff accounts, and offered to customers for sensitive applications.
• Essential: Passwords stored only as strong, salted hashes (for example bcrypt or Argon2), never in plain text or reversible encryption.
• Protection against brute-force attacks: rate limiting and temporary lockouts on login attempts.
• Secure password reset flows with expiring, single-use links.
• Sessions that expire after inactivity and are invalidated on logout and password change.
• Single sign-on (SSO) for staff where possible, so leaving employees lose access in one place.
• A documented process to remove access when employees or contractors leave.

2. Authorization: who can see and do what

Broken access control is consistently one of the most common serious web vulnerabilities, ranked at the top of the OWASP Top 10. It happens when an application checks that a user is logged in, but not whether that user is allowed to access a specific record.

• Essential: Every request that reads or changes data checks that the current user is allowed to access that specific record, not just that they are logged in.
• Essential: In multi-customer applications, data is strictly separated, so one customer can never see another customer's records by changing an ID in the URL.
• Role-based permissions follow the principle of least privilege: users get only the access they need.
• Admin functions are protected separately and, ideally, restricted by network or MFA.
• Automated tests verify access rules for critical data.

3. Data protection

• Essential: HTTPS everywhere, with HTTP redirected to HTTPS and HSTS enabled.
• Essential: Sensitive data (personal data, financial details, health information) identified and stored only where necessary.
• Encryption at rest for databases, backups and file storage.
• Additional encryption for especially sensitive fields such as government ID numbers.
• Payment card data handled by a PCI-compliant provider (such as Stripe), so card numbers never touch your servers.
• Data retention rules: old data you no longer need is deleted, reducing what could be exposed.
• Personal data handling aligned with applicable privacy laws, such as state privacy laws in the U.S.

4. Secure code

• Essential: Protection against injection: database queries use parameterized statements or a framework ORM, never string concatenation with user input.
• Essential: Output is escaped to prevent cross-site scripting (XSS); user-generated HTML is sanitized.
• Forms are protected against cross-site request forgery (CSRF).
• File uploads are validated (type, size), stored outside the public web root or in private storage, and never executed.
• Security headers configured: Content Security Policy, X-Frame-Options or frame-ancestors, X-Content-Type-Options and Referrer-Policy.
• Error messages shown to users do not reveal stack traces, queries or system details.
• Every code change is reviewed by a second developer before release.

Modern frameworks such as Laravel protect against many of these by default, but only if developers use them correctly. We explain this in why we build web applications with Laravel.

5. Dependencies and updates

Modern applications depend on hundreds of open-source packages. Vulnerabilities in these packages are discovered constantly, and attackers scan the internet for systems that have not been patched.

• Essential: The language, framework, database and operating system are on versions that still receive security updates.
• Essential: Automated dependency vulnerability scanning in your development pipeline.
• Security updates applied within days for critical issues, and on a regular schedule otherwise.
• A yearly plan for major framework upgrades, so you never fall far behind.
• Unused packages and features removed.

6. Secrets management

• Essential: API keys, passwords and tokens are never stored in source code or committed to the repository.
• Secrets are stored in environment configuration or a secrets manager, with access limited to those who need it.
• Different credentials for development, staging and production.
• Keys are rotated when people leave or when a leak is suspected.
• Third-party API keys have the minimum permissions required.

7. Infrastructure and hosting

• Essential: Servers and cloud accounts protected with MFA, and administrative access limited to named individuals.
• Firewalls allow only required ports; databases are not reachable from the public internet.
• Production, staging and development environments are separated; production data is not copied to developer laptops.
• Infrastructure changes are documented or, better, defined as code.
• A web application firewall (WAF) or DDoS protection for public-facing applications.
• You (not only your vendor) have owner-level access to domains, hosting and cloud accounts.

8. Backups and recovery

• Essential: Automated daily backups of databases and uploaded files.
• Essential: Restores are tested regularly. A backup that has never been restored is a hope, not a plan.
• Backups stored in a separate location or account from production, protected against deletion by ransomware.
• Defined recovery objectives: how much data you can afford to lose and how quickly you need to be back online.

9. Logging, monitoring and alerting

• Essential: Error tracking and uptime monitoring with alerts to someone who will act on them.
• Security-relevant events logged: logins, failed logins, permission changes, data exports and admin actions.
• Logs retained long enough to investigate incidents, and protected from tampering.
• Alerts for unusual activity, such as spikes in failed logins or large data exports.
• Sensitive data (passwords, card numbers, tokens) never written to logs.

10. Incident response

• A short, written plan: who is contacted, who decides, how systems are isolated and how customers are informed.
• Contact details for your development partner, hosting provider and legal counsel in one place.
• Awareness of notification obligations under applicable breach notification laws.
• A review after every incident to prevent it from happening again.

11. People and process

• Staff trained to recognize phishing, which remains one of the most common ways attackers get in.
• Security considered at the start of every new feature, not added at the end.
• Regular security reviews: a technical audit or penetration test at least yearly for applications handling sensitive data.
• Vendors and contractors held to the same standards through contracts and access controls.

Where to start if you can only do five things

1. Turn on MFA for every administrative account: application, hosting, domain registrar and e-mail.
2. Update the framework, language and server software to supported versions.
3. Verify that access checks protect every customer's data from every other customer.
4. Set up automated, off-site backups and test a restore.
5. Add error tracking and uptime monitoring with alerts.

These five measures address a large share of the incidents we see in small and mid-sized businesses.

Frequently asked questions

Is my small business really a target?

Yes. Most attacks are automated: bots scan the internet for known vulnerabilities and weak passwords regardless of company size. Smaller businesses are often hit because they are easier targets.

How often should we review application security?

Continuously through code review and automated scanning, with a broader review or penetration test at least once a year and after major changes.

Is cloud hosting secure by default?

Cloud providers secure their infrastructure, but you are responsible for how you configure and use it. Misconfigured storage, open databases and weak account security are common causes of cloud data exposure.

Do we need SOC 2?

Not legally, but enterprise customers increasingly ask for it, especially for SaaS products. Many of the items in this checklist are also SOC 2 controls, so following it is a good first step.

Security is a habit, not a project

No application is ever perfectly secure, but most breaches exploit basic, preventable gaps. Working through this checklist and keeping it up to date puts your business well ahead of the attackers looking for easy targets.

Want an independent view of your application's security? A technical audit reviews code, dependencies, access control and infrastructure and gives you a prioritized action plan. Contact us to discuss your application.