How to leverage security frameworks and libraries for secure code

Why Rolling Your Own Security Is a Bad Idea

Writing security controls from scratch is risky even for experienced developers. Attackers routinely exploit tiny implementation flaws, and getting things right for 99% of known payloads is not enough — that remaining 1% can leave your application just as exposed as having no protection at all. A single overlooked edge case in authentication, authorization, or output encoding can completely undermine your security posture.

The alternative is to leverage existing security libraries and frameworks. This goes beyond authentication and authorization libraries — it includes tools that protect against common attack classes like XSS and injection. Building on a widely used, security-focused library means benefiting from years of community testing and improvement. A library used across thousands of applications is exercised far more thoroughly than any purpose-built solution for a single project.

Evaluating Security Dependencies

Popularity from search engine results is not a substitute for due diligence. When choosing a security library or framework, examine it against the following criteria.

Community Adoption

A package used broadly across the ecosystem is more likely to have been audited by multiple independent reviewers. Check metrics like GitHub stars and package manager download counts to gauge adoption.

Reputation

Reputation is subjective, but past experience, online community sentiment, and rankings from security review organizations (for example, Snyk or Microsoft) all provide useful signals.

Active Maintenance

An unmaintained package cannot be trusted to ship security fixes in a timely manner. As a rough benchmark, check whether issues and pull requests have been closed or merged within the last nine months.

Project Maturity

An experimental project may be missing security-critical functionality. Consider whether most features are implemented and whether current RFCs/specs are supported. Look for telltale signs like numerous TODO comments in the codebase, and any available roadmap status.

Security Stewardship History

Good maintainers fix security issues quickly and disclose them publicly. Look through the source repository's issues and security advisories to see whether findings are actively resolved and disclosed. Sources include package providers (e.g., npm audit, Dependabot), MITRE's CVE database, and the GitHub Advisory Database. A high volume of Dependabot findings against the repository is actually a positive signal — it indicates active scanning and remediation activity.

Frameworks With Security Built In

Security libraries are not just for authentication and authorization. The framework you build on matters just as much. For XSS, you could apply an output encoding library to every piece of user-controlled data before rendering. But consistently and correctly applying encoding is hard — especially in nested contexts like a JavaScript event handler inside an HTML attribute. Miss one spot or apply the wrong encoding type, and the application is vulnerable regardless of how many fixes you got right elsewhere.

A better approach is to use a framework that handles encoding transparently. Ruby on Rails' ActiveView helpers such as link_to, for example, automatically encode data in rendered responses. XSS remains possible only when developers explicitly opt out with directives like html_safe or raw. Auditing those explicit, dangerous opt-outs is far more tractable than reviewing every place user data is rendered. The same logic applies to SQL injection: ORM frameworks make queries secure by default, leaving only explicit native query calls as the exception to review. The principle is that insecure behavior should never be the default — it should require an explicit, auditable decision.

Defining and Enforcing Security Invariants

Establish a list of properties that must always hold true for your codebase. These "secure invariants" define your security barriers and tell you what to test on every new commit. Examples include:

• Rails html_safe or raw must not be used
• ActiveRecord's ActiveRecord::Base.connection.execute must not be used
• Framework CSRF protection must not be disabled
• Security headers like X-Frame-Options, X-XSS-Protection, and X-Content-Type-Options are set
• Communication must occur over TLS
• dangerouslySetInnerHTML must not be used in React applications

Lightweight static analysis can enforce these invariants directly in your CI/CD pipeline via GitHub code scanning with semantic CodeQL queries. CodeQL operates across the SAST spectrum — from full program analysis with complex data flow and control flow queries, to simple AST-based semantic matches that run nearly instantly.

For example, a CodeQL query detecting uses of html_safe or raw in Rails code:

import ruby

from MethodCall call

where call.getMethodName() = ["html_safe", "raw"]

select call

And a query to find calls to ActiveRecord::ConnectionAdapters.execute:

import ruby

import codeql.ruby.ApiGraphs

select API::root()

        .getMember("ActiveRecord")

        .getMember("Base")

        .getReturn("connection")

        .getReturn("execute")

Running these on every pull request will raise an immediate flag when any defined security invariant is violated. These query examples are illustrative only — they do not catch every XSS-capable or SQL-injection-capable method.

Security Headers

Frameworks with secure defaults typically add protective headers to every response automatically. Rails, for instance, includes a standard set of default headers by default.

Of these, X-XSS-Protection is arguably better left disabled. The client-side XSS filters it enables have historically been unreliable and in some cases created new attack vectors. Server-side, context-aware encoding is the more dependable defense. For frameworks that don't set headers automatically, at minimum set X-Frame-Options to DENY or SAMEORIGIN to block UI redress (clickjacking) attacks, and X-Content-Type-Options to nosniff to prevent MIME sniffing and hotlinking. Headers are one layer in a broader security-in-depth strategy — do not rely on them exclusively.

Wrapping and Keeping Dependencies Current

Encapsulate external security libraries behind your own API wrappers. This makes usage patterns enforceable, and simplifies swapping out a dependency if it becomes unmaintained.

A track record of CVEs in a library should be weighed carefully: it reflects accumulated expertise as much as past flaws. Rather than counting vulnerabilities, look at how they were fixed. Repeat occurrences of the same vulnerability type indicate a weak security culture. Good projects proactively scan for known patterns, publish security advisories with CVE IDs, and mark security releases clearly. If a project silently fixes vulnerabilities or fails to disclose them, consider a different dependency for your security-critical functionality.

Finally, keep security dependencies current using a software composition analysis (SCA) tool like GitHub Dependabot to catch known-vulnerable versions before they reach production.

Don’t Build Security From Scratch

Writing secure code doesn't mean writing every security control yourself. The ninth OWASP Proactive Control is a reminder to lean on established tools rather than inventing your own protections. This approach reduces risk by relying on code that has already been battle-tested by a larger community.

The principle is straightforward: prefer mature frameworks that offer "security batteries" integrated into their core design. These frameworks already handle common threats and edge cases in their default configurations. By using them, you inherit a baseline of secure behavior without having to reason through every possible attack vector on your own.

When a full framework doesn't cover a specific need, don't write that component from scratch either. Look for existing, proven libraries that solve the problem. The key is to select libraries that are actively maintained and have a track record of responsible vulnerability disclosure.

Integrating these libraries requires discipline to be effective:

• Encapsulate external dependencies. Wrap the third-party library in your own class or service interface. This creates a single point of control, making it easier to swap out a library for a patched version or a better alternative without touching the rest of your codebase.
• Centralize security invariants. Use your wrapper classes to define and enforce your application's specific security requirements, such as encryption strength or allowed input patterns.
• Verify with static analysis. Use automated tools to scan your code for violations of those security requirements. Static analysis helps ensure that developers don't accidentally bypass the encapsulated protections or introduce calls to insecure functions.

The underlying theme is to stop wasting effort on re-implementing cryptography, authentication, input sanitization, and other defense mechanisms from zero. The community has already solved these problems. Your job is to select the right tool, encapsulate it cleanly, and enforce its correct usage across your organization.