Web App Security Basics Every Business Owner Should Ask About

Broken access control sits at the top of the OWASP Top 10. It means a user can reach data or actions they shouldn't — another customer's order, an admin page, someone else's records. The fix is to check permissions on the server for every request, not just hide buttons in the interface.

Good answer: 'Every page and action checks the user's role on the server, and we test that users can't access each other's data.'

Passwords must never be stored in plain text or with fast, outdated hashes. OWASP recommends slow, salted password hashing algorithms such as Argon2id, scrypt or bcrypt. Logins should be rate-limited against guessing, and two-factor authentication offered for admin accounts.

Injection attacks happen when input from a form or URL is treated as code — for example, inserted directly into a database query. Parameterised queries (or a data layer that uses them automatically) prevent SQL injection. Output should be escaped so user content can't inject scripts into pages.

Frameworks, libraries and plugins release security fixes regularly. Ask who applies updates, how often, and how they're tested. Unmaintained dependencies are one of the most common ways sites get compromised.

Collect only the personal data you need, protect it, and delete it when it's no longer required. India's Digital Personal Data Protection Act, 2023 sets obligations for organisations handling personal data, including consent and security safeguards. Keep a simple record of what data you collect, why, and where it's stored.

If you suspect a breach, speed and order matter. Write this down before you need it.

Small businesses can't run a security department, and don't need to. Most attacks exploit basic, well-known weaknesses. Getting the fundamentals right — updates, strong authentication, least-privilege access, parameterised queries, backups — removes most of the risk at little cost. An occasional external review before major launches adds confidence.

Any public form or login can be abused: password-guessing, spam submissions, scraping. Rate limiting — capping how many attempts a network or account can make in a period — stops most automated abuse cheaply. Combine it with a honeypot field on public forms, account lockouts or delays after repeated failed logins, and alerts when limits are hit unusually often.

HTTPS protects data in transit and is expected on every page. Security headers add defence in depth: a Content Security Policy limits which scripts can run, reducing the impact of injected code; other headers prevent the site being framed by other sites or browsers guessing file types. These are small configuration changes with meaningful protection.

Every analytics tag, chat widget and library runs with your site's trust. Keep a list of what's installed and why, remove what's unused, and load third-party scripts only on pages that need them. For code dependencies, automated alerts for known vulnerabilities make it practical for small teams to stay current.

Uploads are a common attack route. Restrict accepted types to what's genuinely needed (for example images and PDFs), check the actual file content rather than trusting the file name, limit size, store uploads outside the application code, and never serve user-uploaded HTML or scripts from your main domain.

Every few months, review who has admin access to the app, hosting, domain, database and third-party services, and remove anyone who no longer needs it. Former staff and past contractors with lingering access are a common, avoidable risk.

Give contractors their own accounts rather than shared logins, grant only the access their task needs, and remove it when the work ends. Keep code, hosting and domains in your organisation's name.

Security isn't a feature you add once. Schedule a short review every quarter: updates applied, access reviewed, backups restored in a test, logs checked. Small, regular habits prevent most incidents.