A library is secure by default when the simplest way to use it is also the safe way. Judge this before adoption by reading its quick start, checking default settings, looking for safe patterns such as parameterized queries, and finding its security guidance. If the easy path is the risky path, expect misuse.
Why defaults matter more than features
Most security bugs in application code come from how a library is called, not from a flaw inside it. If a database library lets you build queries by string concatenation as the obvious example, some of your engineers will do it. If its main example uses parameters, they will copy that.
The OpenSSF evaluation guide groups these ideas under usability and security: check that the API is easy to use securely, for example by supporting parameterized queries, that default configurations and simple examples are secure, and that documentation explains how to use the software securely.
Four checks
- Read the quick start as an attacker would. Does the first example disable certificate checks, accept any origin, skip authentication or turn on verbose errors? Examples are copied into production.
- Inspect the defaults. Run the library with no configuration and see what it does. Note anything that opens a port, accepts untrusted input or writes to disk.
- Look for a safe API next to the unsafe one. Good libraries make the dangerous option long and explicit, for example a function name that says unsafe, and make the safe option short.
- Find the security guidance. A short page on threat model, hardening settings and known pitfalls is a good sign. Its absence is a gap you will fill with your own notes.
A comparison table
| Property | Better | Worse |
|---|---|---|
| Quick start | Uses safe settings | Disables checks to look simple |
| Dangerous options | Named and opt in | Default on |
| Input handling | Parameterized, escaped by default | Manual concatenation |
| Errors | Generic by default | Stack traces in responses |
| Documentation | Has security guidance | None |
Wrap it if it is not safe
If you must use a library with risky defaults, put a thin wrapper around it in your codebase. The wrapper sets the safe options once, hides the dangerous ones, and gives reviewers one place to look. Add a test that fails if someone calls the library directly in application code.
Do it again when versions change
Defaults can change between versions, and sometimes get safer. Read release notes for changed defaults before upgrading. A change that tightens a default can break a working feature, which is why a good project announces it clearly. That announcement quality is itself a signal about the maintainers.
Interface stability also counts. The same guide says to look for a stable API or a policy for breaking changes, because a library that changes its API often makes the safe path harder to keep.
Try it yourself
Open the demo and watch a pull request gate block a risky change. Think about which of your library rules could run the same way.
Click through it at your own pace, or open it full screen.
Quick check
Is a popular library always secure by default?
No. Popularity says nothing about defaults. Read the quick start and test the default behavior yourself.
What is the cheapest way to improve a risky library's defaults?
Wrap it once in your own code with safe settings, and block direct calls with a test or lint rule.
Safeguard's policies, gates and guardrails can enforce rules like these in pull requests, and its SBOM and dependency scanning shows which libraries you are using. Try the free scan.
Sources
Last reviewed: 19 October 2026.
