VIGIL uses cookies to maintain session security and measure anonymous usage. No assessment data is shared with third-party analytics. Privacy Policy

Home How It Works Applications Use Cases Economics About Get in Touch
Security & Trust

OWASP Top 10 —
how VIGIL addresses
each risk.

The OWASP Top 10 is the globally recognised standard for application security risks. This declaration documents precisely how VIGIL addresses each of the ten risk categories — control by control, not category by category.

Framework: OWASP Top 10 (2021) ASVS Level 2 aligned Version 1.0 · July 2026 Self-declared · Annual review
Declaration Statement

Anshin Risk and Resilience Consulting Private Limited (ARRC Global) confirms that the VIGIL security and resilience intelligence platform is developed and operated in accordance with the OWASP Top 10 (2021) application security risk framework. Every control listed in this declaration is implemented — not aspirational.

This is a self-assessed declaration. It does not constitute third-party certification. VIGIL undergoes independent Vulnerability Assessment and Penetration Testing (VAPT) by a CERT-In empanelled security firm at least annually. Enterprise clients may request the VAPT executive summary under NDA.

For the complete technical implementation, refer to the Secure Development Policy. For AI-specific security governance, refer to the AI Governance Policy. For independent verification, contact contact@arrcglobal.com.

A01:2021

Broken Access Control

A01:2021 — Most Critical Risk
Broken Access Control
CRITICAL
Controls Implemented
  • Server-side RBAC enforced on every API request. Client-side access controls are UI convenience only — they are never the enforcement mechanism.
  • Cross-client data isolation enforced at the database access layer — not only at the application layer. No query can return data belonging to a different client organisation.
  • IDOR protection with authorisation checks on all object references before data is returned.
  • Privilege escalation paths explicitly restricted. No user can elevate their own permissions through the platform interface.
  • Quarterly access review — all internal access rights reviewed and confirmed or revoked.
  • Regression tests written for all authorisation logic — every confirmed authorisation vulnerability receives a regression test before fix deployment.
  • Dormant accounts auto-suspended after 60 days of inactivity.
A02:2021

Cryptographic Failures

A02:2021 — Critical Risk
Cryptographic Failures
CRITICAL
Controls Implemented
  • Data at rest: AES-256 encryption on all stored data — databases and file storage.
  • Data in transit: TLS 1.3 minimum on all connections. TLS 1.0 and TLS 1.1 are disabled.
  • Password hashing: bcrypt or Argon2 with appropriate work factors. MD5 and SHA-1 are prohibited for any security-relevant purpose.
  • Cryptographic key management via a dedicated secrets management system. Keys are never hardcoded in source code or configuration files.
  • No sensitive data transmitted in URLs, query strings, or HTTP headers without encryption.
  • Cryptographically secure random number generation for all security-sensitive values — tokens, session IDs, nonces.
A03:2021

Injection

A03:2021 — Critical Risk
Injection
CRITICAL
Controls Implemented
  • All database queries use parameterised statements or prepared queries. String-concatenated SQL construction is prohibited by code review policy.
  • Input validation uses allowlist (whitelist) logic server-side. Unknown input types are rejected, not sanitised. Client-side validation is supplementary only.
  • SAST scanning on every commit for injection patterns including SQL, command, LDAP, and XML injection.
  • ORM-level protections supplemented by query-level validation for complex queries.
  • File uploads validated for type, size, and content. Uploaded files stored outside the web root and never executed.
  • Output encoding applied in all rendering contexts — HTML, JavaScript, URL, and CSS — to prevent Cross-Site Scripting (XSS).
A04:2021

Insecure Design

A04:2021 — High Risk
Insecure Design
HIGH
Controls Implemented
  • STRIDE threat modelling conducted for all significant new features and architectural changes before implementation begins.
  • Security requirements defined as a mandatory pre-development gate — no feature progresses to implementation without documented security requirements.
  • Secure design principles documented in the Secure Development Policy and enforced through the development lifecycle gate process.
  • Data minimisation applied at the design stage — no data field is added without a documented purpose. No speculative data collection.
  • Separation of duties enforced architecturally — no individual can both initiate and approve a sensitive operation without a second authorised party.
  • Defence in depth — no single control relied upon to prevent a security failure; controls are layered.
A05:2021

Security Misconfiguration

A05:2021 — High Risk
Security Misconfiguration
HIGH
Controls Implemented
  • Security headers enforced on all responses: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy.
  • Post-deployment header verification automated — every production deployment confirms security headers are correctly applied.
  • No default credentials — no shared accounts, no factory-default passwords on any system.
  • Environment separation enforced: development, staging, and production are isolated with separate credentials. Production credentials never appear in development environments.
  • Infrastructure configuration version-controlled — all server and security configuration stored in version control, reviewed on change.
  • Directory browsing disabled on all web-accessible paths. Error messages never expose internal paths, stack traces, or system information.
A06:2021

Vulnerable & Outdated Components

A06:2021 — High Risk
Vulnerable & Outdated Components
HIGH
Controls Implemented
  • Automated dependency scanning on every commit and daily against the production dependency set. Findings triaged within 24 hours.
  • SBOM (Software Bill of Materials) maintained and updated with every release — available to enterprise clients on request.
  • Severity-based remediation SLAs: Critical — 7 days · High — 14 days · Medium — 30 days · Low — next maintenance release.
  • Production dependencies pinned to specific versions. Floating version ranges are prohibited in production dependency specifications.
  • Dependencies sourced from official registries only — no unverified third-party code, GitHub snippets, or CDN-linked libraries in production.
  • Dependency inventory reviewed quarterly — unused dependencies removed. Every dependency must have a documented purpose.
  • Licence compliance checked on all dependencies before introduction. Incompatible licences are not added.
A07:2021

Identification & Authentication Failures

A07:2021 — High Risk
Identification & Authentication Failures
HIGH
Controls Implemented
  • JWT tokens with short expiry: access tokens 15 minutes; refresh tokens 7 days with rotation on every use.
  • MFA mandatory for all administrative and privileged accounts. Available and strongly encouraged for all platform users.
  • Account lockout after 5 consecutive failed attempts with progressive delay and alert generation.
  • Breach-password checking at account creation and password change — passwords checked against known compromised credential databases.
  • Password requirements: minimum 12 characters, complexity enforced, no reuse of previous 10 passwords, maximum age 12 months.
  • No persistent 'remember me' tokens beyond defined session limits. Sessions expire after 15 minutes of inactivity.
  • Concurrent sessions from different geographic locations generate a security alert requiring re-verification.
A08:2021

Software & Data Integrity Failures

A08:2021 — Medium Risk
Software & Data Integrity Failures
MEDIUM
Controls Implemented
  • Immutable production deployments built from verified source at a specific commit reference. Post-deployment modification of running code is prohibited.
  • CI/CD pipeline access controls restrict who can modify deployment configuration. Pipeline configuration is version-controlled and audited.
  • All dependencies sourced from official package registries only — no unverified external code or inline scripts.
  • Pre-commit scanning for secret patterns blocks commits containing API keys, tokens, or connection strings before they reach version control.
  • Backup integrity verification — each backup hash-verified at creation; hashes stored separately and verified before any recovery operation.
  • Rollback capability confirmed before every production deployment.
A09:2021

Security Logging & Monitoring Failures

A09:2021 — Medium Risk
Security Logging & Monitoring Failures
MEDIUM
Controls Implemented
  • Central logging captures all authentication events, authorisation decisions, data access operations, and administrative actions.
  • Log retention: 12 months minimum. Logs stored in append-only mode during normal operations — cannot be modified or deleted by application-level processes.
  • Alerting configured for anomalous patterns including repeated authentication failures, unusual data access volumes, access from new geographic locations, and concurrent sessions.
  • Audit trail covers all sensitive operations — every privileged access session logged at the command or action level, not only at the authentication event.
  • Failed login logs retained 12 months for brute force detection and security investigation.
  • Security incident records retained 5 years from incident closure for regulatory and legal purposes.
A10:2021

Server-Side Request Forgery (SSRF)

A10:2021 — Medium Risk
Server-Side Request Forgery (SSRF)
MEDIUM
Controls Implemented
  • All server-side URL fetching validated against an allowlisted domain set. No user-controlled URL is accepted for server-side fetching without explicit allowlist validation.
  • Internal network ranges (RFC 1918) blocked from all outbound server-initiated requests — prevents access to internal infrastructure via SSRF.
  • DNS rebinding protections applied to prevent attackers from bypassing IP-based allowlists through DNS manipulation.
  • HTTP redirects validated before following — redirect targets checked against the allowlist, not assumed safe.
  • No user-controlled input accepted in server-side network operations without explicit validation and sanitisation against the allowlist.
Declaration Details

Version, scope & review

This declaration is self-assessed and published in good faith. Controls listed are implemented as of the effective date. This declaration is reviewed annually and updated when the OWASP Top 10 framework is revised or when material changes to the platform's security architecture occur.

Declaration Version1.0
FrameworkOWASP Top 10 (2021 edition) — owasp.org/www-project-top-ten/
ASVS AlignmentOWASP Application Security Verification Standard (ASVS) Level 2
Effective Date01 July 2026
Review CycleAnnual, or upon OWASP framework update or material platform change
Issuing EntityAnshin Risk and Resilience Consulting Private Limited (ARRC Global)
PlatformVIGIL — vigil.arrcglobal.com
Contactcontact@arrcglobal.com
VAPTIndependent VAPT conducted annually by a CERT-In empanelled security firm. Executive summary available to enterprise clients under NDA.
Related Documents Secure Development Policy · AI Governance Policy · Trust & Security · Responsible Disclosure