Safety Norms: Web Application Security

1Purpose, Scope, and Safety Principles

These norms govern the security-relevant work of building, changing, testing, hosting, and supporting web applications. The scope includes front-end code, application programming interfaces, databases, identity services, third-party components, cloud configuration, and the build pipeline. They apply to employees, contractors, and volunteers who touch those systems.

Three principles guide every rule: least privilege, defense in depth, and fail-safe behavior. Words such as must mark mandatory rules required by internal policy. Words such as should mark accepted practice that teams may adapt only with documented justification.

• Least privilege: grant each account only the permissions its current task requires.
• Defense in depth: no single control, including a firewall or a framework default, is treated as sufficient on its own.

2Roles, Competence, and Accountability

The application owner is accountable for the risk accepted for a system. The security lead maintains these standards, reviews high-risk changes, and approves exceptions. Developers, platform engineers, and testers apply controls in their daily technical work. Operations staff own logging, backups, availability, and incident containment tools.

Authority follows competence. Access to production data, secrets, and administrative consoles is granted only after documented authorization. Where a person lacks training for a task, the task is assigned to someone who has it or is performed under direct supervision.

• The application owner must record each accepted residual risk in the risk register with a named approver.
• Only staff with documented authorization may access production data, secrets, or administrative consoles.
• Security testers must hold written authorization from the system owner before testing any system they do not own.
• Recommended: complete role-based secure coding training before receiving production write access.
• Any person may halt a deployment that appears to expose sensitive data, and must report the halt immediately.

3Realistic Hazards and Risk Assessment

Common hazards include injection flaws such as SQL and command injection, cross-site scripting, broken authentication and session management, broken access control such as insecure direct object references, server-side request forgery, insecure deserialization, misconfigured cloud storage, secrets exposed in source code or logs, vulnerable third-party libraries, and unsafe file uploads. Each can lead to data disclosure, account takeover, unauthorized actions, or outage. The list is illustrative, not exhaustive.

Risk is estimated from likelihood and impact on users and the organization. Teams rate each feature as low, medium, or high using the documented scale. High-risk features require a threat model before release. Risk assessments must be reviewed when architecture, data classification, or internet exposure changes.

• Broken object-level authorization exposing customer records: treat as high priority in every release.
• Credential theft from tokens left in logs, repositories, browser storage, or client code.
• Denial of service through unbounded queries, large uploads, or missing rate limits on login endpoints.
• Supply chain compromise through unpinned, abandoned, or unreviewed dependencies.
• Production impact caused by running intrusive tests or destructive payloads against live systems.
• Insider misuse enabled by standing administrative rights that are never reviewed.

4Preventive Controls and Secure Development Practices

Preventive controls belong in the design stage, not after a finding. Input must be validated against an allowlist for expected type, length, and format. Output must be encoded for the context where it is rendered, such as HTML, attributes, JavaScript, or URLs. Database queries must use parameterized statements or the safe query interfaces of the approved framework. Authorization decisions must be enforced on the server for every request, because interface hiding is not a security control.

Dependencies, secrets, and configuration receive the same discipline as application code. Build pipelines should block components with known serious vulnerabilities according to the approved policy. Changes to authentication, authorization, cryptography, payment flows, and sensitive data handling require peer review before merge. Where a framework or library offers a secure default, teams should keep that default unless a documented exception exists.

• Must enforce authentication and authorization checks on every server-side endpoint, including internal APIs.
• Must store passwords using a current password hashing function approved by the security lead, never reversible encryption or plain text.
• Must serve all traffic over TLS using certificates from a trusted issuer, and should enable HTTP Strict Transport Security where the platform supports it.
• Must set session cookies with the Secure and HttpOnly attributes and an appropriate SameSite value.
• Must keep secrets, private keys, and tokens out of source code, client-side scripts, and log output, and must store them in the approved secrets manager.
• Must not disable framework protections such as anti-forgery tokens or output escaping without a documented, time-limited exception.
• Should deploy a content security policy that restricts script sources and avoids inline scripts.
• Must validate uploaded files by type, size, and storage location, and must never execute uploaded content from the web root.
• Should apply rate limits and resource quotas to authentication, search, and other expensive endpoints.
• Must confirm that error responses reveal no stack traces, query text, or internal paths to end users.

5Authorized Testing and Safe Operating Practices

Security testing, including vulnerability scanning, manual penetration testing, and fuzzing, can disrupt service, corrupt data, or create legal exposure when performed without permission. Authorization must be written and must name the systems, environments, permitted techniques, test window, emergency contacts, and stop conditions. Permission to test one application does not extend to shared hosting, third-party services, or upstream providers.

This section is educational guidance. Staff without formal training and approval must not attempt intrusive testing. Testing outside authorization may breach computer misuse laws in many jurisdictions, and those laws vary, so confirm the rules with qualified legal counsel.

• Must test only in environments named in the written authorization. Production testing requires explicit owner approval and a tested rollback plan.
• Must use dedicated test accounts and synthetic data. Real customer records must never be used as test inputs.
• Must configure scanners with rate limits and schedule intrusive tests outside peak business hours agreed with the owner.
• Must not run denial-of-service tests against shared infrastructure or third-party services.
• Must stop testing immediately when unexpected latency, errors, or data changes appear, and must notify the incident contact.
• Should keep a test log recording tool versions, targets, start and end times, and operator names.
• Must use proof-of-concept exploits only to the extent needed to confirm a finding, and must not publish exploit code in public forums.
• Must report findings only through the agreed channel and store evidence in encrypted, access-controlled storage.

6Data Privacy, Environment, and Protective Safeguards

Web applications often process personal, financial, health, or credential data. Data must be classified before development, and the classification determines the safeguards required. Logs, analytics events, error pages, debugging tools, and browser storage are frequent leakage points. Development, test, and production environments must be separated, with independent credentials, separate databases, and network boundaries.

Protective safeguards also cover the working environment. Developers and administrators working in shared or public spaces must lock screens when away, avoid displaying credentials or production dashboards, and use only managed devices for privileged work. Personal protective equipment is not normally relevant to this subject, but these physical and digital hygiene steps prevent the most common accidental exposures.

• Must minimize collected personal data to what the feature needs, and must document the lawful basis or consent approach that applicable privacy rules require.
• Must mask or remove personal data from logs, error messages, and analytics events before storage.
• Must disable debug modes and verbose diagnostics in production.
• Must restrict administrative interfaces to approved networks and require multi-factor authentication for privileged accounts.
• Must encrypt sensitive data at rest and in transit using approved mechanisms, with keys stored separately from the data they protect.
• Must maintain an inventory of third-party scripts, tags, and embedded services, approved by the security lead before deployment.
• Should use a web application firewall as one layer of defense, never as a substitute for secure code.
• Must use separate administrator accounts for privileged work and ordinary accounts for email and browsing.

7Incident Response, Escalation, and Emergencies

Suspected incidents include successful unauthorized logins, unexpected data exposure, defacement, file encryption by unknown processes, malicious code in a dependency, and sustained service degradation. Any person who notices a suspected incident must report it immediately to the on-call security contact and the application owner. Reporting must not wait for proof, and no one should investigate beyond safe containment steps on their own.

The incident lead coordinates containment, evidence preservation, communication, and recovery. Legal and privacy teams decide whether breach notification duties apply, because those duties vary by jurisdiction and contract. If a person's physical safety is at risk, contact emergency services first. Web incidents rarely create that situation, but systems that control physical equipment can.

• Report every suspected incident through the channel in the incident policy. When uncertain, report.
• Preserve logs, snapshots, and affected configurations. Do not delete, overwrite, or edit evidence.
• Contain by disabling the affected account, token, or endpoint rather than shutting down the whole platform, unless the incident lead approves a full shutdown.
• Rotate credentials suspected of exposure before restoring service.
• Keep a tested rollback plan for each release, and confirm that it works before deployment.
• Do not contact customers, regulators, or media without approval from legal and communications staff.
• Record near misses, such as blocked attack attempts or staging data accidentally visible in production, and review them like incidents.

8Records, Training, Monitoring, and Review

Records prove that controls operate. Keep current architecture diagrams, data flow maps, threat models, dependency inventories, access reviews, exception approvals, and test reports. Records should be reviewed when a system changes significantly and at an interval the owner sets in the risk register.

Training must be role based. Developers need secure coding practice, administrators need hardening and access management instruction, and testers need authorization and safe testing practice. Measures such as open high-risk findings, overdue exceptions, and time to contain incidents show leaders whether these norms are working.

• Must review administrator and service account access at a defined interval and remove accounts that are unused or unowned.
• Must record every exception with an owner, an expiry condition, and a compensating control.
• Should hold post-incident reviews that produce tracked corrective actions with named owners.
• Should run automated scanning and dependency checks in the build pipeline and track results to closure.
• Should update these norms when platform guidance, applicable laws, or lessons learned change, and confirm jurisdiction-specific requirements with qualified professionals.

Implementation checklist

• Confirm written authorization covering systems, environments, and techniques before any security test.
• Keep secrets, keys, and tokens out of source code, client scripts, and logs.
• Enforce server-side authorization checks on every endpoint, including internal APIs.
• Use parameterized queries and context-aware output encoding for all user-controlled data.
• Classify data before build and mask personal information in logs and analytics.
• Run tests only in approved environments, using synthetic data and rate limits.
• Report suspected incidents immediately, contain narrowly, and preserve evidence.
• Record every exception with an owner, expiry condition, and compensating control.
• Verify applicable laws, standards, and vendor instructions with qualified professionals in your jurisdiction.