SaaS Security Best Practices: What Your Development Agency Should Know

Security is a property, not a feature

One of the most expensive misunderstandings in software development is treating security as a feature — something to add during a dedicated security sprint before launch, or something to address after the first incident. By the time you add security as a retrofit, the decisions that created the vulnerabilities have already been made and hardening them requires unpicking work that should have been done correctly the first time.

A development agency that treats security properly builds it in from the start. This post outlines what that looks like in practice — both so you know what to expect from a quality agency, and so you can ask the right questions if you are evaluating one.

Authentication and session management

Authentication is the front door of your SaaS product. Done poorly, it is the most direct path for attackers. The basics that any quality agency should handle as standard:

• Never storing passwords in plain text. Passwords should be hashed using a modern algorithm (bcrypt, Argon2, or PBKDF2) with appropriate work factors. This should go without saying, but it still gets done wrong.
• Session tokens that are cryptographically random and sufficiently long. Session IDs should be generated with a cryptographically secure random number generator, not sequential integers or predictable values.
• Secure cookie attributes. Session cookies should be marked HttpOnly (not accessible to JavaScript), Secure (only transmitted over HTTPS), and use SameSite to prevent cross-site request forgery.
• Rate limiting on authentication endpoints. Without rate limiting, brute-force attacks against login endpoints are trivial. This should be implemented from day one.
• Multi-factor authentication. For any SaaS handling sensitive data, MFA should be supported and ideally required. It is the single most effective measure against account takeover.

Input validation and injection prevention

SQL injection remains one of the most common and damaging vulnerabilities in web applications. It happens when user input is interpolated directly into database queries rather than handled through parameterised queries or prepared statements. Any agency that is not using parameterised queries for all database interactions in 2024 is not operating to an acceptable standard.

The same principle applies to other types of injection: command injection (user input passed to shell commands), template injection (user input rendered in server-side templates), and cross-site scripting (user input rendered in HTML without proper escaping).

These vulnerabilities are well-understood and well-documented. Preventing them is not difficult if you are following modern development practices. Ask your agency specifically how they handle user input in database queries — the answer should reference parameterised queries or an ORM that handles this safely.

Secrets management

API keys, database credentials, and other secrets should never be committed to source code repositories. This sounds obvious, but it happens regularly, often because a developer commits a config file that contains a secret while testing and forgets to remove it before pushing.

A quality agency uses environment variables or a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, or equivalent) to store and access secrets. They have pre-commit hooks or CI checks that detect secrets being committed to version control. And they have a process for rotating compromised secrets quickly.

Transport security

All traffic between clients and your servers should be encrypted via TLS. This should be enforced — not just supported — meaning HTTP requests should be redirected to HTTPS, and HSTS (HTTP Strict Transport Security) headers should be configured so browsers remember to use HTTPS for your domain.

Certificates should be properly managed and renewed before they expire. Expired certificates cause immediate trust failures and service disruption. Automated certificate management (Let's Encrypt or similar) removes the risk of human error here.

Access control

Every endpoint in your application should enforce access control checks — not just authentication (is the user logged in?) but authorisation (does this user have permission to do this specific thing?).

The most common access control failures in SaaS applications:

• Endpoints that check authentication but not authorisation, allowing any authenticated user to access any tenant's data by modifying request parameters
• Admin endpoints that rely on obscurity (a hidden URL) rather than proper access control
• API endpoints that perform different access control checks than the equivalent UI, creating bypass opportunities

Access control should be tested explicitly — including tests that attempt to access resources belonging to a different tenant or user, to confirm the controls are working correctly.

Dependency management

Modern SaaS applications depend on dozens or hundreds of third-party libraries, each of which can introduce security vulnerabilities. A responsible agency keeps dependencies updated and has a process for responding quickly to security advisories affecting dependencies the project uses.

Tools like npm audit, Safety (Python), or Dependabot can automate dependency vulnerability scanning. Automated dependency updates with CI validation make keeping dependencies current much less painful. Ask your agency what their approach to dependency management is — it is a relatively low-effort security measure that many teams ignore.

What to ask your agency

Here are specific questions to ask a development agency about their security practices:

• How do you handle database queries to prevent SQL injection?
• How do secrets and credentials get managed in your projects?
• How do you verify that one tenant cannot access another tenant's data?
• Do you include security testing as part of your development process?
• How do you keep third-party dependencies updated?
• Have you worked on products that required compliance with GDPR, PCI DSS, or similar regulations?

An agency that is doing security properly will answer these questions specifically and without hesitation. Vague reassurances are not sufficient.