Direct answer: "We follow security best practices" is not a verifiable claim on its own. A vendor should be able to explain, specifically, how they mitigate each major risk category — injection, broken authentication, misconfiguration — in their actual build process, and whether a formal code review or penetration test has ever validated that in practice. Ask for specifics before handing over real user data, not after a breach.
What citing the OWASP Top 10 should actually mean
The OWASP Top 10 is a regularly updated, widely referenced list of the most critical web application security risk categories. A vendor citing it as a standard is a reasonable starting signal, but the real test is whether they can walk through specifically how each category gets mitigated in their own build process — parameterized queries against injection, secure session handling and password hashing against broken authentication, dependency scanning against known-vulnerable components. Reciting the list by name without being able to explain the mitigations is a weaker signal than it sounds.
Security code review vs. penetration test
A security-focused code review examines the actual source for vulnerable patterns — unsanitized inputs, weak authentication logic, secrets committed to the repository — and is most valuable early, since it catches structural problems before they are deployed. A penetration test simulates a real attack against the live, running application, probing for exploitable weaknesses the way an actual attacker would, and validates the deployed system rather than just the source. Neither replaces the other; a mature security posture uses both at different points in the project lifecycle.
When a formal penetration test is actually warranted
Applications handling payment data, health records, or other sensitive personal information — and anything expected to scale to meaningful financial or reputational risk — warrant a professional penetration test before launch and periodically afterward. A simple marketing website or low-risk internal tool typically does not need that level of investment; a solid code-level review and adherence to security fundamentals is proportionate there. Match the security investment to the actual data and risk involved, not a blanket policy either way.
Security fundamentals that should never be skipped
HTTPS enforced everywhere with no mixed content, passwords hashed with a modern algorithm and never stored in plain text, parameterized database queries to prevent SQL injection, input validation at every boundary where external data enters the system, and dependencies kept current against known vulnerabilities. These apply regardless of project size or budget — a vendor cutting any of these to save cost is cutting the wrong corner, on any project.
How user data should actually be protected once live
Encryption in transit via TLS, encryption at rest for genuinely sensitive fields, role-based access control limiting who and what can reach specific data, monitoring that would actually surface unusual access patterns, and a documented plan for what happens if a breach is suspected. Ask a vendor to describe each of these concretely for your specific application — a generic policy statement without specifics is not the same as a real answer. Our own approach to this is covered in more depth in our enterprise data security guide.
If your project handles patient data specifically, see our healthcare app architecture guide for the additional considerations that apply there.
Sources
External references behind the figures and claims on this page. Rate bands and vendor pricing move — check the source before quoting a number.
- OWASP Top Ten Web Application Security Risks
OWASP Foundation
The specific risk categories (injection, broken authentication, security misconfiguration) a vendor should be able to name concrete mitigations for.
Frequently Asked Questions
What does "we follow OWASP Top 10" actually mean, and is it enough?
The OWASP Top 10 is a regularly updated list of the most critical web application security risks — things like injection flaws, broken authentication, and security misconfiguration. A vendor citing it should be able to explain specifically how each risk is mitigated in their standard build process (parameterized queries against injection, proper session handling against broken authentication, and so on), not just cite the list by name. Reciting OWASP as a buzzword without specifics is a weaker signal than a vendor walking through their actual mitigations.
What is the difference between a security code review and a penetration test?
A security code review examines the source code itself for vulnerable patterns — unsanitized input, weak authentication logic, exposed secrets — typically done by the development team or an independent reviewer with code access. A penetration test simulates a real external attack against the running application without necessarily having source access, probing for exploitable vulnerabilities the way an actual attacker would. Both are valuable; a code review catches structural issues earlier and cheaper, a penetration test validates the deployed system under real attack conditions.
Does my project actually need a formal penetration test?
It depends on what the application handles. Apps processing payment data, health records, or other sensitive personal information, or anything expected to handle scale and real financial risk, warrant a professional penetration test before or shortly after launch, and periodically afterward. A simple marketing site or internal tool with no sensitive data typically does not need the same investment — a solid code-level review and standard security practices are proportionate for that risk level.
What security basics should be non-negotiable regardless of project size?
HTTPS enforced everywhere with no mixed content, passwords hashed with a modern algorithm (never stored in plain text or reversibly encrypted), parameterized database queries to prevent SQL injection, input validation at every boundary where external data enters the system, and dependencies kept current against known vulnerabilities. These apply to every project regardless of budget — a vendor skipping any of these on cost grounds is cutting the wrong corner.
How does user data actually get protected once the app is live?
Encryption in transit (HTTPS/TLS) and, for genuinely sensitive fields, encryption at rest; role-based access control so only authorized users and systems can reach specific data; logging and monitoring that would surface unusual access patterns; and a documented incident response plan for what happens if a breach is suspected. Ask a vendor to describe each of these concretely for your specific project, not as a generic policy statement.
What security questions should I ask a vendor before signing?
How they handle authentication and password storage specifically; whether they run dependency vulnerability scans and how often; what their process is if a security issue is discovered post-launch; whether a penetration test has ever been performed on a comparable past project; and how user data is encrypted both in transit and at rest. Vague, reassurance-only answers to these are a signal to probe further before handing over real user data.