Security & Technical Notes | Tools by Atharva

Tools by Atharva is designed as a predominantly static, browser-side application that minimises the amount of user information that needs to reach an application server.

1. Security architecture

Tools by Atharva uses static HTML, CSS and JavaScript together with browser APIs and, for some specialised functions, browser-side WebAssembly.

The design objective is to avoid transmitting file contents where the requested operation can be completed locally.

2. Local file processing

Images, PDFs, audio, video, GIFs, documents and collage images used by ordinary processing tools are intended to remain in the browser.

There is no intended silent fallback that sends difficult files to a Tools by Atharva remote processing server.

3. HTTPS

Production access should be provided exclusively over HTTPS. Plain HTTP requests should redirect to HTTPS.

Both supported hostnames should use valid TLS certificates:

tools.atharva.info
webtools.atharva.info

4. Content Security Policy

A restrictive Content Security Policy should be delivered as an HTTP response header by the production web server or security edge.

The policy should permit only resources genuinely required by the application and should reject unexpected executable content.

In particular:

object-src 'none' should remain enforced;
framing should be prohibited;
unnecessary third-party script origins should not be added;
unexpected analytics injection should be disabled rather than whitelisted;
runtime dependency origins should be removed as dependencies are self-hosted.

5. Recommended response headers

The production deployment should maintain security headers equivalent to:

Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), geolocation=(), payment=(), usb=(), serial=(), bluetooth=(), microphone=(self)
Cross-Origin-Opener-Policy: same-origin
X-Permitted-Cross-Domain-Policies: none

HSTS includeSubDomains or preload should only be enabled after verifying the impact across all applicable subdomains.

6. Browser permissions

Powerful browser features should be denied unless required.

Microphone access is needed only for explicit audio-recording functionality and should remain limited to the same origin.

Camera, geolocation, payment, USB, serial and Bluetooth access are not required by the normal tool suite and should remain unavailable unless a future feature explicitly requires them.

7. Cloudflare

Cloudflare may be used for DNS, TLS, proxying, caching, availability and security.

Production configuration for both hostnames should remain consistent.

Recommended settings include:

SSL/TLS mode: Full (strict);
Web Analytics / browser RUM: disabled unless intentionally required;
Rocket Loader: disabled;
Zaraz: disabled unless intentionally required;
unexpected JavaScript injection: disabled;
equivalent cache and security rules for both hostnames.

8. External dependencies

Some advanced tools may use version-pinned third-party browser libraries or WebAssembly components.

Version pinning reduces unintended upgrades but does not eliminate software-supply-chain risk.

The preferred long-term production configuration is to:

audit the exact dependency release;
verify upstream licences and checksums;
self-host JavaScript and WebAssembly resources;
remove unnecessary CDN fallbacks; and
tighten the Content Security Policy accordingly.

9. File safety

Client-side processing avoids unnecessary uploads but does not make malformed files harmless.

Large, damaged or intentionally hostile files may consume significant CPU or memory and can cause:

slow processing;
high memory consumption;
browser warnings;
WebAssembly failures; or
tab crashes.

Tools should reject unreasonable inputs where practical rather than send them to an undisclosed remote processor.

10. PDF operations

PDF tools perform browser-side operations wherever supported.

Some operations may rasterise a document and can therefore alter searchable text, document structure, metadata, accessibility information, forms or existing signatures.

A visual signature inserted into a PDF must not be confused with a certificate-backed cryptographic digital signature.

Users should retain original copies of important documents.

11. OCR

OCR operations are intended to run in the browser.

The application should avoid retaining OCR source documents or recognised text after the browser working session unless the user explicitly saves or copies a result.

12. Audio and video processing

Media processing may use Web Audio, browser codecs or WebAssembly media components.

Large media files can consume significant memory. Users should avoid closing the page or putting the device to sleep while a long-running operation is active.

13. Microphone recordings

The recording tool requires explicit browser permission. Recorded data should remain in browser memory until the user downloads it or leaves the processing page.

14. No application persistence of processed files

The application is designed not to use persistent browser storage to retain ordinary file-processing inputs or outputs.

Generated Blob/Object URLs should be revoked after they are no longer necessary, and large temporary objects should be released where practical.

15. External lookup tools

Certain utilities inherently require external information.

Examples include exchange-rate and IP-information lookups. Such requests should occur only when the user invokes the relevant tool.

These network requests should never be used as a hidden pathway for transferring files selected in unrelated local tools.

16. XSS and DOM safety

New functionality should prefer safe DOM APIs such as textContent, explicit element creation and direct attribute assignment instead of injecting untrusted HTML.

HTML input should be sanitised where rendering user-supplied markup is genuinely required.

17. Cache management

Security-sensitive HTML or JavaScript updates should not remain stale because of excessively long CDN caching.

Static versioned assets may use long-lived caching, while HTML documents should use a policy that allows timely deployment of security fixes.

Cloudflare caches for both hostnames should be purged when emergency client-side fixes are deployed.

18. Server logs

Server and CDN logs should not intentionally contain locally processed file contents, generated passwords, document contents, audio recordings or locally generated outputs.

Infrastructure metadata may be retained where operationally, legally or security-wise necessary.

19. Two-hostname configuration

The following hostnames are intended to serve the same application:

https://tools.atharva.info
https://webtools.atharva.info

tools.atharva.info should be treated as the canonical public hostname.

Both hostnames should use the same release, document root, Cloudflare security posture and browser security headers.

20. Responsible vulnerability disclosure

We welcome responsible reports concerning genuine security vulnerabilities.

Please include, where possible:

the affected URL or tool;
browser and operating system;
clear reproduction steps;
observed security impact; and
a minimal non-destructive proof of concept.

Please do not intentionally access another person's information, degrade service availability, perform destructive testing or attempt social engineering.

21. Security contact

Security reports should be sent privately to:

Email: [email protected]

Location:
Pune, Maharashtra, India

22. Jurisdiction

Tools by Atharva is operated from Pune, Maharashtra, India.

Security and incident-response practices are subject to applicable Indian law and mandatory legal or regulatory requirements.

23. Security limitations

Security controls reduce risk but cannot eliminate every possible vulnerability in browsers, third-party dependencies, operating systems, network infrastructure or user devices.

This page describes the intended security architecture and is not a guarantee that any software system is immune from compromise.