Secure Coding Practices and Standards (OWASP, CERT Checklist)

Secure coding practices are the habits that keep exploitable flaws out of source code: validate input on the server, keep data away from interpreters (parameterized queries, output encoding, no shell), check authorization on every request, keep secrets out of the repository, use vetted cryptography, fail closed, and keep dependencies current. A secure coding standard writes those practices down as numbered, checkable rules for your languages and frameworks. Teams usually build theirs from OWASP for web and API code, SEI CERT for C, C++ and Java (MISRA where safety certification applies), and the CWE Top 25 to decide what the rules must prevent.

Below: the standards compared, a checklist by category, and the 2025 CWE Top 25 mapped to prevention and detection. Invadel’s part is verification: an independent secure code review that traces every finding to the file and line, from $4,800 at a fixed price with a free re-review (see the secure code review price tiers).

Secure coding practices vs secure coding standards

A practice is a principle (“validate all input on the server”). A standard is a numbered, testable rule for a specific stack (“all database access goes through the parameterized query layer”). SEI CERT draws the line formally: a rule is one whose violation is likely to cause a defect affecting safety, reliability or security, and whose conformance can be checked; anything else is a recommendation. Copy that discipline. Unenforceable advice gets ignored; rules a linter or reviewer can check get followed.

Secure coding standards compared (status November 2026)

Standard	What it covers	Status
OWASP Secure Coding Practices Quick Reference Guide	Language-neutral checklist, 14 sections	Archived; moved into the OWASP Developer Guide
OWASP Top 10 Proactive Controls	Ten controls developers should build in	2024 edition
OWASP ASVS 5.0.0	Testable requirements at three levels	Published May 30, 2025
SEI CERT coding standards	Rules for C, C++, Java, Android, Perl, Fortran	C and C++ 2016 editions; now hosted on GitHub
MISRA C:2025, MISRA C++:2023	Restricted C and C++ for safety-critical code	MISRA C:2025 published March 2025
MITRE CWE Top 25	The most dangerous weaknesses, ranked	2025 list
NIST SSDF (SP 800-218)	PW.5: follow secure coding practices	Version 1.1 final (February 2022); draft 1.2 (Rev. 1) since December 2025
CISA and FBI Product Security Bad Practices	Practices software makers should eliminate	Version 2.0, January 2025

OWASP secure coding practices

The OWASP Secure Coding Practices Quick Reference Guide is where most searches for a secure coding checklist land: more than 200 technology-neutral items in 14 sections, from input validation to memory management. OWASP has archived it and moved the checklists into the OWASP Developer Guide web application checklist, which follows the 2018 edition of the OWASP Top 10 Proactive Controls (the 2024 edition renames and reorders them). The OWASP Top 10 says what goes wrong most often, the Cheat Sheet Series explains implementation, and OWASP ASVS turns it into requirements you can put in a contract or test scope.

SEI CERT coding standards

The SEI CERT coding standards from Carnegie Mellon’s Software Engineering Institute are the most detailed free language standards. Every rule has an identifier you can quote in a review comment, noncompliant and compliant examples, and a risk score: severity, likelihood and remediation cost, each 1 to 3, multiplied into a priority from 1 to 27. Scores of 12 to 27 are Level 1, 6 to 9 Level 2, and 1 to 4 Level 3.

CERT’s language-neutral top 10 secure coding practices: validate input, heed compiler warnings, architect and design for security policies, keep it simple, default deny, adhere to least privilege, sanitize data sent to other systems, practice defense in depth, use effective quality assurance techniques, and adopt a secure coding standard.

Elsewhere: MISRA C where safety certification applies, Oracle’s Secure Coding Guidelines for Java SE, Microsoft’s secure coding guidelines for .NET, and OWASP MASVS for mobile, which pairs with the OWASP Mobile Top 10 risks.

Secure coding best practices: checklist by category

Condensed from the OWASP and CERT material above. CWE numbers tie each item to scanner output and to the Top 25 table below.

Input validation

• Validate every input on the server against an allowlist of type, length, format and range; client-side checks are for usability only (CWE-20).
• Treat headers, cookies, file names, webhooks, queue messages, partner APIs and language model output as untrusted. Normalize first, then validate at a defined trust boundary.
• Never build a file path from user input; map an ID to a path you control (CWE-22).
• For uploads, check type by content, cap size, rename, and store outside the web root (CWE-434).

Output encoding and injection

• Use parameterized queries or a query builder for every database call, even for “internal” values (CWE-89).
• Let the template engine encode output for its context, and flag every raw HTML sink in review (CWE-79).
• Do not call a shell; use library functions or argument lists with an allowlist (CWE-78, CWE-77).
• Never evaluate input as code, whether through eval, dynamic imports or user-editable templates (CWE-94). This rule and the one above, with the deserialization and upload rules, are what prevent remote code execution.
• Do not deserialize untrusted data in a native object format; use a data-only format with a schema (CWE-502). Disable external entities in XML parsers (XXE).

Authentication and sessions

• Use your framework’s or identity provider’s authentication, and require it on every route by default, with public routes as documented exceptions (CWE-306).
• Hash passwords with a slow, salted algorithm built for the job, such as Argon2id, scrypt or bcrypt.
• Make reset tokens random, single-use and short-lived, and rate-limit login, reset and MFA endpoints.
• Issue a new session ID at login, set cookies Secure, HttpOnly and SameSite, end sessions server-side at logout, and protect state-changing requests against CSRF (CWE-352).
• Validate every token’s signature, algorithm, issuer, audience and expiry on the server.

Access control

• Deny by default and enforce authorization on the server for every request, in one shared component (CWE-862, CWE-284).
• Check ownership, not just role: every lookup by ID must confirm the record belongs to the caller’s user or tenant (CWE-639, CWE-863). Our guide to IDOR vulnerabilities shows how this fails.
• Never trust a role, price, tenant ID or account ID sent by the client, and bind request bodies to an allowlist of fields so nothing is mass-assigned (CWE-915).
• Make one-time actions and balance changes atomic so parallel requests cannot redeem a code or spend a balance twice (CWE-362).
• Allowlist the destinations of server-side requests and block internal and cloud metadata addresses (CWE-918).

Cryptography and secrets

• Use vetted libraries and current algorithms; never design your own scheme. Generate tokens with a cryptographically secure random generator.
• Keep secrets out of source, fixtures and CI logs; load them from a secrets manager and scan every commit (CWE-798). GitGuardian counted more than 28.6 million new secrets in public GitHub commits in 2025 (State of Secrets Sprawl 2026). Our CI/CD pipeline security guide covers secrets in pipelines.
• Use TLS everywhere and never disable certificate validation, even “temporarily.”

Errors, logging and data protection

• Fail closed: an exception in an authorization or payment check must deny, not continue. The OWASP Top 10 2025 added Mishandling of Exceptional Conditions for this reason.
• Show users generic errors and return only the fields a caller needs; keep stack traces in server logs (CWE-200).
• Log failed logins, access denials and validation failures, never passwords, tokens or card numbers.
• Encrypt sensitive data at rest, keep it out of URLs, and mark sensitive responses no-store.

API-specific rules

The categories above apply to APIs as written. The OWASP API Security Top 10 (2023) adds three rules that web-page thinking tends to miss:

• Check object ownership on every endpoint that takes an ID, and function-level permission on every admin or role-specific route (API1 Broken Object Level Authorization, API5 Broken Function Level Authorization).
• Return and accept only an explicit list of fields for each role, so a response never leaks a property and a request never sets one it should not (API3 Broken Object Property Level Authorization).
• Keep an inventory of every API host and version and retire the old ones, and validate data from third-party APIs like any other input (API9 Improper Inventory Management, API10 Unsafe Consumption of APIs).

Our API security best practices guide covers the design side of each.

Memory management (C and C++)

• Use bounds-checked functions and ban the unsafe classics (CWE-787, CWE-125, CWE-120).
• Define ownership of allocated memory, prefer RAII and smart pointers, and reset pointers after freeing (CWE-416). Check pointers and function return values for null before use (CWE-476).
• Treat compiler warnings as errors (the “clean build” in NIST SSDF task PW.6.2), enable hardening options, and fuzz parsers with sanitizers.
• Write new components in a memory-safe language where you can. Around 70% of Chromium’s high-severity security bugs are memory safety problems (Chromium project), and CISA and the FBI asked software makers to publish memory safety roadmaps by the end of 2025 (Product Security Bad Practices).

Dependencies, configuration and limits

• Use approved, maintained libraries, pin versions, scan every build, and fix known exploited vulnerabilities before release.
• Ship secure defaults: debug off, no default passwords, least-privilege database accounts, and security headers such as Content-Security-Policy and HSTS.
• Cap request size, upload size, page size, query complexity, timeouts and request rates (CWE-770).
• Review AI-generated code like any other code; see the security risks of vibe coding.

The 2025 CWE Top 25, mapped to the practice that prevents it

MITRE built the 2025 CWE Top 25 from 39,080 CVE records published between June 1, 2024 and June 1, 2025 (methodology). “Review” means a person reading the code; “manual test” means a person attacking the running application with accounts in more than one role.

Rank	Weakness	Practice that prevents it	Usually caught by
1	CWE-79 Cross-site scripting	Context-aware output encoding	SAST, DAST
2	CWE-89 SQL injection	Parameterized queries	SAST, DAST
3	CWE-352 Cross-site request forgery	Framework CSRF tokens, SameSite cookies	DAST, manual test
4	CWE-862 Missing authorization	Deny by default, central checks	Review, manual test
5	CWE-787 Out-of-bounds write	Bounds-checked APIs, memory-safe languages	Fuzzing, SAST
6	CWE-22 Path traversal	Map IDs to paths	SAST, DAST
7	CWE-416 Use after free	Ownership rules, RAII	Fuzzing with sanitizers
8	CWE-125 Out-of-bounds read	Bounds checks	Fuzzing with sanitizers
9	CWE-78 OS command injection	No shell, argument lists	SAST, DAST
10	CWE-94 Code injection	Never evaluate input	SAST, review
11	CWE-120 Classic buffer overflow	Size-checked copies	Compiler warnings, SAST
12	CWE-434 Dangerous file upload	Content checks, storage outside web root	Review, manual test
13	CWE-476 NULL pointer dereference	Check return values	SAST, compiler
14	CWE-121 Stack-based buffer overflow	Bounds checks, stack protection	Fuzzing, SAST
15	CWE-502 Untrusted deserialization	Data-only formats	SAST, review
16	CWE-122 Heap-based buffer overflow	Bounds checks, memory-safe languages	Fuzzing with sanitizers
17	CWE-863 Incorrect authorization	Ownership and tenant checks	Review, manual test
18	CWE-20 Improper input validation	Server-side allowlists	Every method, partially
19	CWE-284 Improper access control	One shared access-control layer	Review, manual test
20	CWE-200 Information exposure	Generic errors, explicit response fields	DAST, manual test
21	CWE-306 Missing authentication	Authentication on by default	Review, manual test
22	CWE-918 Server-side request forgery	Outbound allowlist	Review, manual test
23	CWE-77 Command injection	No shell, argument lists	SAST, DAST
24	CWE-639 User-controlled key (IDOR)	Scope lookups to user or tenant	Review, manual test
25	CWE-770 No resource limits	Size, rate and time limits	Manual test

Two patterns stand out. Six entries (CWE-787, 416, 125, 120, 121 and 122) are memory-safety weaknesses that a memory-safe language removes as a class. A seventh, CWE-476 NULL pointer dereference, still happens in Java, C#, Go and Python, where it raises an exception or panic instead of causing undefined behavior. Five (CWE-862, 863, 284, 306 and 639) are authentication and authorization flaws, where scanners help least because no tool knows which user should own which record. Those five deserve your most specific rules and the most human attention. Our SAST vs DAST vs IAST comparison shows what each tool sees, and our SAST tools guide covers choosing one.

How to write a secure coding standard developers will follow

A standard copied wholesale from OWASP or CERT runs to hundreds of items and gets ignored. A useful one is short, specific to your stack, and wired into existing tools.

1. Scope it. Name the languages, frameworks and repositories it covers, and its owner.
2. Pick baselines. The OWASP Developer Guide checklist and ASVS Level 2 for web and API code, MASVS for mobile; SEI CERT for C, C++ and Java, plus MISRA C or MISRA C++ where safety certification applies.
3. Write rules, not aspirations. Each rule gets an ID, a one-line requirement, a “do this instead” example from your own code, and the CWE it prevents.
4. Name approved and banned components: one authentication library, one cryptography library, one HTML sanitizer, and the functions nobody may use.
5. Map each rule to its enforcement: linter, SAST rule, scanner, or the review checklist, where authorization and business-logic rules belong by name. NIST SSDF task PW.5.1 asks teams to follow secure coding practices suited to their languages, and PW.7.2 asks for code review based on the organization’s secure coding standards (NIST SP 800-218).
6. Set an exception process. A documented, time-limited exception beats a silent scanner suppression.
7. Roll out by risk, CERT Level 1 first, adding rules once CI enforces the first set.
8. Review it yearly, and whenever a test finds a new class of flaw.

An example rule

Step 3 in practice. A written rule can be this short:

Field	Example
ID	AC-03
Requirement	Every lookup of a record by ID must also filter by the caller’s tenant ID, taken from the server-side session.
Do this instead	Call the shared findForTenant(session.tenantId, id) helper; never query by id alone.
Prevents	CWE-639, authorization bypass through a user-controlled key
Enforced by	The review checklist, plus a lint rule that flags direct queries outside the data-access layer

A reviewer can cite “AC-03” in a pull request comment, a scanner finding tagged CWE-639 maps straight to it, and an exception to it has to be written down.

Our secure software development lifecycle guide shows where the standard sits among the other phases, and building a secure code review program covers aiming human review at the code that matters.

Which regulations expect secure coding

Framework	Clause	What it asks for
PCI DSS v4.0.1	6.2.4	Techniques that prevent or mitigate injection, attacks on data and data structures (buffers, pointers, shared data), cryptography misuse, business logic abuse (including XSS and CSRF), access control bypass, and any high-risk vulnerabilities identified under 6.3.1
ISO/IEC 27001:2022	Annex A 8.28	Secure coding principles applied to software development

Neither names a particular standard. They ask that you have one, that developers know it, and that you can show it was followed. The secure development lifecycle guide above covers the process rules around it, such as developer training and code review before release (PCI DSS 6.2.2 and 6.2.3), NYDFS 500.8, SOC 2 CC8.1 and the EU Cyber Resilience Act. See our PCI DSS and ISO 27001 pages for how that evidence is used.

How Invadel verifies secure coding, and what it costs

We do not write coding standards or run developer training; we check code against them, independently.

A secure code review checks code the way your standard intends: AI-assisted analysis covers what a linter could enforce, and a senior reviewer verifies every candidate and reads the authentication, access control, payment, file handling and tenant code by hand. Send your languages and your coding standard when you scope the review: we confirm coverage before quoting, and the reviewer sees what you have already required or banned. Findings are traced to the file and line and mapped to CWE and OWASP ASVS, the same references a good standard cites, so each one points back to the rule it breaks.

Pricing is fixed in writing: from $4,800 for one module or high-risk feature, and from $12,000 for large or multi-repository codebases; the secure code review cost guide shows the tiers and what moves the price. The developer walkthrough after delivery puts the broken rules in front of the people who write the code, and the free re-review once fixes merge closes them in the report. Executive and technical reports, an attestation letter and our findings platform are included.

To see what a broken rule lets an attacker do in the running product, add a web application penetration test, from $5,200 with a free retest.

Frequently asked questions

What are the top 10 secure coding practices? OWASP’s version is the Top 10 Proactive Controls (2024): access control, cryptography, input validation and exception handling, security from the start, secure defaults, secure components, digital identity, browser security features, logging and monitoring, and stopping server-side request forgery. SEI CERT’s list starts with validate input and heed compiler warnings.

Which secure coding standard should we use? For web and API code, the OWASP Developer Guide checklist with ASVS Level 2; for mobile apps, OWASP MASVS. For C and C++, SEI CERT, plus MISRA where safety certification applies. For Java, CERT’s Oracle standard. Add a short internal rule set for your frameworks.

What is the difference between OWASP ASVS and a secure coding standard? ASVS lists what must be true of the finished application, as testable requirements at three levels. A secure coding standard is your team’s rules for how code is written in your languages and frameworks so those requirements are met. Use ASVS to decide what to require and test, and the coding standard to say how.

How often should a secure coding standard be reviewed? At least yearly, and sooner when a penetration test, code review or incident finds a new class of flaw, a framework you depend on changes major version, or a baseline such as ASVS or the CWE Top 25 is reissued.

Is the OWASP Secure Coding Practices checklist still maintained? No. OWASP archived the Quick Reference Guide and moved its checklists into the OWASP Developer Guide. The 14-section checklist is still a sound starting point.

Which is not a secure coding practice? Client-side-only validation, blocklisting “bad” characters, home-made cryptography, hiding endpoints instead of protecting them, hard-coded credentials, disabled certificate validation, and swallowing exceptions so the code carries on.

How do you verify developers follow a secure coding standard? Automate what you can with linters, SAST and secret scanning on every pull request, put the rest on a review checklist, and bring in independent review for high-risk code. Where manual code reviews are used, PCI DSS 6.2.3.1 requires a reviewer other than the author who knows code review and secure coding, and management approval before release.

The short version

Secure coding practices are habits; a secure coding standard makes them specific, numbered and enforceable for your stack. Build yours from OWASP and SEI CERT, aim it at the 2025 CWE Top 25, automate what tools can check, and put people on authorization and logic. For an independent check of your code, scope a secure code review: from $4,800, fixed price, free re-review (all secure code review pricing).