Secure Coding and OWASP ASVS — DedSec Project

Purpose: Convert security expectations into concrete software requirements and verification tests using modern secure-development practices and OWASP ASVS 5.0.

Secure coding is a system

Secure code depends on architecture, frameworks, dependencies, deployment, secrets, logging, identity, and operational controls. A developer can write memory-safe input handling and still ship an insecure product if authorization is missing.

ASVS as a requirements catalog

OWASP Application Security Verification Standard (ASVS) 5.0.0 provides application-security requirements that teams can use for architecture, development, procurement, and verification. Use the requirements relevant to the application's risk and context rather than treating ASVS as a checkbox contest.

Input validation

Define the allowed shape of data by type, length, range, format, encoding, and business rules. Validate on the trusted side of the boundary. Client-side validation improves UX but cannot enforce server security.

Output handling

Encode data for the destination context: HTML text, HTML attribute, JavaScript, URL, SQL, shell, and other interpreters have different syntax and risks. Prefer frameworks and APIs that provide context-aware escaping or parameterization.

SQL and data stores

Use parameterized queries or safe ORM patterns. Database authorization should also limit application account privileges; preventing injection is not a reason to run the application as a database superuser.

Command execution

Avoid invoking shells with user-controlled strings. Prefer direct process APIs and allow-listed operations. Separate data from code.

Authorization

Implement authorization server-side on every protected action. Test both allowed and denied paths. Object identifiers are references, not authorization decisions.

Authentication and session management

Use mature identity libraries and standards. Protect session cookies, rotate session identifiers after security-relevant transitions, enforce logout/revocation behavior, and design secure account recovery.

Error handling

OWASP Top 10:2025 includes mishandling of exceptional conditions as a major risk area. Fail securely, return appropriate client errors, and send detailed diagnostics to protected logs rather than users.

Secrets

Do not embed production secrets in code, mobile binaries, browser JavaScript, container images, or Git history. Use managed secret storage and rotation. Build processes should fail when required secrets are absent rather than silently using weak defaults.

File handling

Treat uploaded filenames, metadata, MIME types, archives, and document formats as untrusted. Generate server-side storage names, enforce size/type policies, isolate processing, and prevent path traversal.

Deserialization and parsers

Prefer simple data formats with strict schemas. Avoid unsafe object deserialization from untrusted sources. Keep parsers updated because complex file formats and protocol implementations carry their own attack surface.

Logging requirements

Applications should log security-significant events with actor, action, target, outcome, and timestamp while excluding passwords, tokens, payment data, and unnecessary personal information.

Dependency security

Track direct and transitive dependencies. Use lockfiles, SBOMs where appropriate, trusted registries, provenance/signing capabilities, and vulnerability monitoring. Remove abandoned dependencies rather than carrying them indefinitely.

Security tests

Include:

• unit tests for validation and authorization;
• integration tests for identity/session behavior;
• negative tests;
• dependency and secret scans;
• static/dynamic analysis where useful;
• infrastructure/configuration checks;
• regression tests for fixed vulnerabilities.

Code review questions

• What data crosses a trust boundary?
• Where is authorization enforced?
• What happens on malformed/unexpected state?
• Could a secret reach logs?
• Does this introduce a new dependency?
• Is concurrency/race behavior safe?
• What happens when the downstream service fails?
• Is there a secure default?

Lab — Security requirement to test

Choose five ASVS requirements relevant to a toy local web app. For each, write:

1. requirement;
2. implementation location;
3. positive test;
4. negative test;
5. evidence;
6. owner.

Learning goal: transform broad security advice into verifiable engineering work.

Primary reference

• OWASP ASVS 5.0: https://owasp.org/www-project-application-security-verification-standard/

Secure coding program guidance

Secure coding works best when security requirements are part of normal development rather than a late penetration-test gate.

Requirements to tests

Convert statements such as “users may only access their own invoices” into automated positive and negative tests. Security requirements should be reviewable, testable, and attached to the code paths that enforce them.

Trust-boundary validation

Validate at the boundary where untrusted data becomes trusted structure. Use schema/type/length/range validation and context-appropriate output encoding. Avoid copying sanitization functions between contexts where their assumptions differ.

Dependencies and build

Review dependency provenance, update policy, transitive risk, build identities, artifact signing/provenance where available, and secret access in CI/CD. A secure source file can still produce an unsafe product through a compromised build/dependency path.

Error and state handling

Define safe behavior for duplicate requests, retries, timeouts, partial failure, invalid state transitions, and dependency outages. Unexpected conditions should fail safely and leave enough audit information to investigate.

Guided study workflow

Before you begin

Modules 14, 22, and basic development.

Practice task

Choose a small application you own. Define five security requirements, map them to ASVS-style verification ideas, add negative tests, fix one issue, and retain evidence of the regression test.

Continue with

Recommended next modules: 41, 52, 53.