Skip to main content
Globalbit
Back to Blog
Best PracticesWeb Development

Security by Design: Building Apps That Pass Penetration Testing the First Time

Published Updated ·Sasha Feldman
Security by Design: Building Apps That Pass Penetration Testing the First Time

TL;DR: Apps pass penetration tests the first time when security is part of how the code is written. Cover the OWASP Top 10 (the 2025 edition puts broken access control first), scan dependencies on every pull request, keep secrets in a vault, validate every input on the server and use platform secure storage on mobile. Security built in from the start costs far less than a fix after the pen test.

Many apps fail their first penetration test

And the fixes eat 2-3 months of development time because security was bolted on at the end instead of built in from the start. We've seen this pattern dozens of times: a company builds an app for 6 months, hires a pen testing firm, and gets a 40-page report of vulnerabilities that require architectural changes.

The alternative is straightforward. Build security into your development process from day one. Not as an afterthought, not as a separate phase, but as part of how you write code.

The OWASP Top 10: what actually gets exploited

The Open Web Application Security Project (OWASP) maintains a list of the ten most critical web application security risks. The current edition is the OWASP Top 10:2025. Most successful attacks exploit these known issues, so addressing them covers much of your risk.

Broken access control is #1 in the 2025 list, as it was in 2021. Users reach data or actions beyond their permissions because an endpoint doesn't check authorization. Enforce permissions on the server for every request, and deny by default.

Injection attacks rank fifth in 2025, down from third in 2021. SQL injection, NoSQL injection, command injection. The fix: never concatenate user input into queries. Use parameterized queries and ORMs. Always. No exceptions. Not for admin tools. Not for internal APIs.

Authentication failures (#7 in 2025, formerly "broken authentication") mean session tokens that are predictable, passwords stored in plaintext, or login flows that don't rate-limit. Use established auth libraries (Clerk, Auth0, Firebase Auth). Don't build your own. Every custom auth system we've audited had at least one critical vulnerability.

Cryptographic failures (#4 in 2025, called "sensitive data exposure" before 2021) happen when data is transmitted without encryption, stored in logs, or accessible through API endpoints that don't check permissions properly. Encrypt at rest, encrypt in transit, and audit every API endpoint for authorization.

Background

Need an app that passes pen testing first time?

We bake security into architecture, not bolt it on later. Our apps consistently pass pen tests without rework.

Practical security practices that work

During development

Dependency scanning. Run Dependabot, Snyk, or npm audit on every pull request. Outdated dependencies with known CVEs are the easiest attack vector. In our last 10 code audits, 8 had critical dependency vulnerabilities that could be exploited with publicly available scripts. The 2025 OWASP list added Software Supply Chain Failures at #3, so dependency checks belong in every pipeline.

Secret management. No secrets in code. Ever. Not in environment files committed to git, not in Docker images, not in Slack messages. Use a vault: HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Rotate secrets quarterly.

Input validation on both sides. Client-side validation is a UX feature. Server-side validation is a security feature. Validate every input on the server: type, length, format, range. Reject anything unexpected.

During code review

Security-focused review checklist. Every pull request should check: Are all inputs validated server-side? Are all database queries parameterized? Are authorization checks present on every endpoint? Are errors handled without exposing internal details?

Automated security linting. Tools like Semgrep and SonarQube catch common security patterns in code. Run them in CI alongside your regular linter.

During deployment

HTTPS everywhere. No exceptions. Including development environments, because developers need to test security features as they'll work in production.

Content Security Policy headers. CSP prevents XSS attacks by telling browsers which sources of content are allowed. A strict CSP is one of the most effective security measures and costs nothing to implement.

Rate limiting on all endpoints. Not just login. Every API endpoint should have a rate limit. Without it, attackers can brute-force anything from password resets to coupon codes.

Mobile-specific security

Mobile apps have additional attack surfaces.

Certificate pinning prevents man-in-the-middle attacks by ensuring your app only communicates with your servers. Implement it. Update pins before certificates expire.

Secure storage. Don't store tokens in UserDefaults or SharedPreferences. Use the iOS Keychain or Android Keystore. These provide hardware-backed encryption that survives device rooting.

Code obfuscation. Mobile apps can be decompiled. Obfuscate your code (ProGuard for Android, Swift's built-in protections for iOS) and never embed API keys or secrets in the binary.

From our work

Check2Fly, Israel's COVID-era border system, was one of the most targeted public systems in the country during the pandemic. Security was part of every sprint from day one: end-to-end encryption, hardened infrastructure and continuous monitoring. It passed government security audits before launch and handled millions of sensitive health records with zero security incidents. For a defense-sector client, we built an internal AI chat that a CISO approved in one meeting, with private networking, a seven-layer security pipeline and zero stored credentials.

Frequently asked questions

How much does security add to development cost? About 10-15% when built in from the start. About 30-40% when bolted on after development. The math is clear.

How often should we do penetration testing? Annually for most applications. Quarterly for financial, healthcare, or applications processing sensitive data. After any major architectural change.

What certifications should our development partner have? ISO 27001 demonstrates organizational security practices. SOC 2 Type II shows audited controls over time. For specific industries, check for relevant compliance knowledge (PCI for payments, HIPAA for healthcare).

Building a security-sensitive application? Talk to our team about security-first development.

[ NEWSLETTER ]

New articles, once a week

One short email a week with the articles we published on the blog.

We keep your email, your name if you add it, and your consent, and use them only to send this update. Read our privacy policy.

[ CONTACT US ]

Tell us what you’re building.

Trusted by 250+ organizations. We respond within one business day.

By submitting, you agree that we may contact you and use your details to measure and improve our advertising, per our privacy policy.

Discuss your Project →