Web and API Security Guide

1. Introduction and Scope

1.0 Normative Language (Mandatory Keywords)

The following keywords are used to express requirement strength in this guide:

• SHALL / MUST: Mandatory requirement. Non-compliance requires an approved exception.
• SHOULD: Recommended requirement. If not implemented, rationale should be documented.
• MAY: Optional requirement.
• MUST NOT / SHALL NOT: Prohibited requirement.

1.1 Purpose

The purpose of this guide is to define how the Government of Malawi secures web applications and APIs. It covers authentication and authorization, input validation and output encoding, protection against OWASP Top 10 and related risks, secure configuration, and API-specific controls (auth, rate limiting, versioning). It applies to applications and APIs developed or operated by or for government that process government or personal data or that are internet-facing or otherwise exposed.

1.2 Scope of Application

This guide applies to all government ministries and departments; state-owned enterprises and parastatals; local government authorities; and government contractors when they develop or operate web applications or APIs for government. It covers custom and commercial applications and APIs; commercial products must be configured and used in line with this guide where applicable.

1.3 Definitions and Key Terms

Web application – An application accessed via browser or web client that processes government or personal data or is internet-facing; must be developed and operated per this guide.

API (Application Programming Interface) – An interface that allows systems or clients to access data or functionality; must be authenticated, authorized, rate-limited, and protected (TLS, input validation).

Authentication – Verification of identity for web/API access; per Malawi Government IAM (e.g. SSO, MFA for sensitive); APIs use token (OAuth 2.0) or certificate-based auth; credentials from Secrets Management.

Authorization – Enforcement of what an authenticated user or client may access or do; role or attribute-based per IAM; enforced at application layer.

OWASP Top 10 – A standard list of the most critical web application security risks (e.g. injection, broken authentication, XSS, sensitive data exposure); applications assessed and designed to address these.

Input validation – Checking and sanitising all user and client input (type, length, format, allowlist) to prevent injection and other attacks; output encoding to prevent XSS.

SAST/DAST – Static Application Security Testing (code analysis) and Dynamic Application Security Testing (runtime testing); used before production for critical and internet-facing applications.

Rate limiting – Restriction of request frequency per client or token to prevent abuse and DoS; applied to APIs per this guide.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Authentication and authorization – 100% of web/API access to sensitive data authenticated per IAM; authorization enforced at application layer; sessions secure (HTTPS, timeout); no credentials in URLs or insecure client storage.

Secure development – Input validated and output encoded; OWASP Top 10 addressed; security testing (SAST/DAST, penetration test) before production for critical and internet-facing applications; dependencies and containers scanned per CI/CD and Vulnerability Management.

Secure configuration – Applications run with secure defaults; no secrets in code or config (use Secrets Management); dependencies updated; debug/admin interfaces disabled or restricted in production.

API governance – APIs authenticated and authorized; rate limiting and throttling; versioning for compatibility and deprecation; TLS 1.2 minimum; documentation does not expose sensitive data.

Integration – Web and API security align with IAM (auth), CI/CD (scanning), PKI (TLS, certificates), Secrets Management, and Vulnerability Management so that the full stack is governed.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor for all ministries):
• Authentication: All web/API access to sensitive or personal data SHALL be authenticated per IAM (SSO, MFA where required); APIs SHALL use token or certificate auth per Section 3.2.1.
• TLS: TLS 1.2 minimum (1.3 preferred) for all web/API traffic.
• Input validation: All user and client input SHALL be validated and output encoded; parameterised queries for DB access.
• Secrets: Credentials and API keys MUST NOT be in code or config; Secrets Management SHALL be used.
• Security testing: Critical and internet-facing applications SHALL be security-tested (SAST/DAST or pentest) before production; findings remediated or excepted.
• API baseline: Exposed APIs SHALL meet the Minimum API Security Baseline (Section 3.2.1); rate limiting SHALL be configured.
• Prohibitions:

MUST NOT deploy critical or internet-facing applications without security test evidence or approved exception.

MUST NOT store secrets in code, config files, or client-side storage.

MUST NOT expose APIs without authentication, authorization, and rate limiting unless explicitly excepted.

MUST NOT grant exception without recording in exception register with compensating controls and expiry.

3. Governance and Compliance Framework

3.1 Governance Structure

Document Owner – The Ministry of Information and Communication Technology (MoICT), Department of eGovernment, owns this guide and is responsible for its maintenance, interpretation, and coordination with other government Guides (including IAM, CI/CD, PKI, and Secrets Management).

System Owner – Accountable for web applications and APIs under their responsibility; approves exception requests within their remit.

Security Officer – Validates that web/API security controls meet this guide and governs exceptions; may review security test results.

Application developer or team – Implements authentication, authorization, input validation, and secure configuration; uses Secrets Management; participates in security testing and remediation.

Operations or DevOps – Ensures production configuration is secure; maintains TLS and dependencies; supports incident response for application-layer incidents.

3.2 Authentication and Authorization

Web and API access is authenticated using government IAM (e.g. SSO, MFA for sensitive or high-impact). APIs use token-based or certificate-based authentication (OAuth 2.0, API keys from Secrets Management, or client certificates per PKI). Authorization is enforced at the application layer (role or attribute-based per IAM). Session management: secure session ID, HTTPS only, timeout after inactivity. Credentials and tokens are not exposed in URLs or client-side storage insecurely.

3.2.1 Minimum API Security Baseline (Mandatory for Exposed APIs)

For any API exposed outside a single trusted boundary (internet-facing or cross-ministry integration), the following SHALL apply:

TLS enforcement – TLS 1.2 minimum (1.3 preferred) for all API traffic.

Authentication – Every request to non-public endpoints SHALL be authenticated (SSO/OAuth2 tokens, mTLS, or equivalent as approved).

Authorization – Authorization SHALL be enforced at the application layer (RBAC/ABAC); deny-by-default.

Token validation – Tokens SHALL be validated for issuer, audience, expiry, and signature; key rotation SHALL be supported where the IdP provides it.

Input validation – Inputs SHALL be allowlisted/validated; outputs encoded where applicable to prevent XSS.

Rate limiting – Rate limiting/throttling SHALL be configured on exposed APIs; bypass requires exception.

Logging – Security-relevant API events SHALL be logged (auth success/failure, access denied, admin actions) and retained per Logging/Evidence.

Secrets – API credentials/keys MUST NOT be embedded in code; Secrets Management SHALL be used.

3.2.2 API Onboarding Checklist (Procedure)

Procedure:

(1) Register API owner and classification (data sensitivity, consumers).

(2) Define auth method and authorization model (roles/scopes).

(3) Configure TLS and key/cert management per PKI.

(4) Implement input validation and output encoding.

(5) Configure rate limiting and abuse monitoring.

(6) Ensure logs are forwarded/retained per Monitoring + Logging/Evidence.

(7) Run required security testing and retain evidence.

(8) Link production exposure to Change Management approval.

3.3 Input Validation and Output Encoding

All user and client input is validated (type, length, format, allowlist). Input is sanitised to prevent injection (SQL, command, etc.). Output is encoded to prevent XSS (e.g. context-appropriate encoding). Parameterised queries or prepared statements are used for database access. File upload (if any) is restricted (type, size, content check); uploaded files are stored outside web root or with strict access control.

3.4 OWASP Top 10 and Secure Development

Applications are designed and implemented to address OWASP Top 10: injection, broken authentication, sensitive data exposure, XML external entities (XXE), broken access control, security misconfiguration, XSS, insecure deserialisation, use of components with known vulnerabilities, insufficient logging and monitoring. Secure development: security requirements in design; code review or SAST; dependency and container scanning (per CI/CD); DAST or penetration test before production for critical and internet-facing. Findings are remediated or accepted with exception.

Procedure:

(1) Include security requirements in design; assess new and significantly updated applications against OWASP Top 10.

(2) Run SAST and dependency scanning in pipeline; run DAST or penetration test before production for critical and internet-facing applications.

(3) Remediate critical and high findings or document exception with System Owner and Security Officer sign-off.

(4) Retain security test results for audit; re-test after material changes.

3.5 Secure Configuration and Dependencies

Applications run with secure defaults (e.g. error messages do not leak internals in production). Debug and admin interfaces are disabled or restricted in production. Secrets (DB credentials, API keys) are from Malawi Government Secrets Management solution. Dependencies (libraries, frameworks) are updated per Malawi Government Vulnerability Management and Software Supply Chain Guides; known vulnerable versions are not used in production.

3.6 API Security

APIs are authenticated and authorized. Rate limiting and throttling are used to prevent abuse and DoS. API versioning supports backward compatibility and deprecation. API documentation (e.g. OpenAPI) does not expose sensitive data. TLS 1.2 minimum (1.3 preferred) for all API traffic (per PKI and Server Hardening).

3.7 Safe Exception Process

Exceptions to mandatory web/API security requirements (e.g. authentication, TLS, input validation) SHALL be requested, documented, and reviewed as follows. Exception requests must include: system or service name; requirement(s) from which exception is sought; justification; compensating controls and timeline; proposed end date; and sign-off from System Owner and Security Officer.

Request via government form or template.

• Documentation: justification; compensating controls and timeline; risk acceptance by System Owner and Security Officer; maximum exception duration (not to exceed 12 months unless re-approved).
• Review: at least quarterly; extensions require re-approval.
• Register: all exceptions SHALL be recorded in an exception register and made available for audit.

4. Verification and Evidence Baseline (Audit-Ready Web and API Security)

To make this guide auditable, ministries and application owners SHOULD maintain evidence that, at minimum, demonstrates:

• Authentication and TLS: Auth method per app/API; TLS config; no credentials in code (scan evidence).
• Security testing: SAST/DAST or pentest reports for critical and internet-facing apps; remediation or exception records.
• OWASP: Assessment or checklist for new/major-update apps; exception register where applicable.
• API baseline: API onboarding records (Appendix D.1); rate limiting and logging config.
• Exception register: All exceptions with requirement, justification, compensating controls, owner, expiry, review date.
• What internal audit checks: (1) Sample of apps/APIs for auth, TLS, rate limiting; (2) security test evidence for critical/internet-facing; (3) exception register validity.
• Sampling approach: Quarterly sample of applications and APIs; annual review of exception register.
• Escalation path: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

4.1 Compliance Reporting

5. Legal Compliance and Training

5.1 Legal and Related Guides

Data Protection Act (2024): security of applications that process personal data.

Electronic Transactions and Cybersecurity Act (2016): cybersecurity.

• Related Guides: Malawi Government IAM Guide; Malawi Government Secrets Management Guide; Malawi Government PKI and Certificate Management Guide; Malawi Government Secure Delivery Guide; Malawi Government Vulnerability Management Guide.
• Training: Developers and operators on this guide, OWASP, secure development, and secure configuration; at role assumption and refreshed at least annually.

6. Framework Alignment

This guide contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.9, A.14, A.12, A.13
• NIST SP 800-53 Rev. 5 – families SA, SC, SI, AC
• Benchmarks – OWASP Top 10 for application security

Refer to `ISO27001_Mapping.md` and `Multi_Framework_Mapping.md` for the complete mapping tables.

7. Appendices

Appendix A: Related Guides

Malawi Government IAM Guide; Malawi Government Secrets Management Guide; Malawi Government PKI and Certificate Management Guide; Malawi Government Secure Delivery Guide; Malawi Government Vulnerability Management Guide.

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• Security controls: Authentication and authorization; TLS; input validation and output encoding; dependency scanning.
• Testing: Security test or SAST/DAST results; exception register with requirement, justification, and review/expiry dates.
• Appendix D: Templates (Minimum)

D.1 API Onboarding Record (Template)

• API name and owner
• Consumers (internal/external) and data classification
• Auth method (SSO/OAuth2/mTLS/API key) and token validation rules
• Authorization model (roles/scopes) and deny-by-default statement
• Rate limit settings and monitoring
• Logging fields and retention location
• Testing evidence links (SAST/DAST/pentest)

References

OWASP Top 10 (current version).

NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (SA-11, SI-10, SC-8).

Data Protection Act No. 3 of 2024 (Malawi).

Electronic Transactions and Cybersecurity Act (2016) (Malawi).