Security

Overview

We design yvcr.com with practical, defense‑in‑depth controls appropriate for a small business site. This page summarizes current measures across transport security, session and form protections, abuse prevention, logging, and file handling.

Transport Security

• HTTPS enforcement: The site forces HTTPS in production to protect data in transit.
• CDN assets with integrity: External libraries (e.g., Bootstrap, Font Awesome) include Subresource Integrity (SRI) where available.

Session & Authentication

• Secure session configuration: Sessions use a custom name with Secure, HttpOnly, and SameSite=Strict flags.
• Timeouts: Certain areas use idle timeouts to reduce risk on shared devices.
• Password storage: User passwords are stored using industry‑standard hashing methods.
• Role‑based controls: Administrative pages are restricted and checked server‑side.
• Scoped store admin session: The store’s management interface uses a distinct session namespace to isolate credentials from general site accounts.

Form & API Protection

• CSRF protection: Forms use server‑validated tokens to prevent cross‑site request forgery.
• Rate limiting & backoff: Repeated actions (like login) are subject to exponential backoff and limits per IP.
• reCAPTCHA: Human verification is used to reduce automated abuse on public forms.
• Input validation & output encoding: User inputs are validated and encoded to mitigate injection risks.
• Deletion confirmation: Destructive actions (e.g., product deletion) require explicit confirmation plus CSRF token validation.

Logging & Monitoring

• Activity and audit logs: Key actions are recorded with timestamps and IP addresses for security review and troubleshooting.
• CAPTCHA and rate‑limit logs: Attempts and outcomes are recorded to identify abuse patterns.
• Error handling: Detailed errors are not exposed to users; issues are logged server‑side.

File Uploads & Downloads

• Non‑executable uploads: Uploaded files are served as static content and are not executed by the server.
• Path whitelisting: File serving endpoints restrict directories and sanitize filenames to prevent traversal.
• MIME checks: Only allowed content types are served for user‑uploaded images/files.
• Web server hardening: Server rules are used to disable script execution in upload folders. Administrative guidance is documented internally.
• Scoped upload areas: Separate folders (e.g., gallery, store) simplify applying least‑privilege rules.

Front‑End Protections

• Email address obfuscation: The public email link is obfuscated client‑side to reduce harvesting by bots; a contact form is also available.
• Theme & UI scripts: Scripts are kept minimal, and external sources are limited to reputable CDNs needed for functionality (Bootstrap, icons, mapping, charting).

Headers & Policies

We aim to apply sensible security headers at the server level. Where supported, we recommend:

• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy limiting unused features (camera, microphone, etc.)
• X-Frame-Options: SAMEORIGIN (or equivalent CSP frame-ancestors)
• Content Security Policy (CSP) tailored to required CDNs and inline needs

CSP is being rolled out incrementally to balance protection with functionality.

Third‑Party Services

We use third‑party services for email delivery (SMTP), reCAPTCHA, and CDNs for static assets. These providers receive limited technical data (e.g., IP address, user agent) needed to deliver the content. See our Privacy Notice for details.

Responsible Disclosure

If you believe you have found a security issue, please report it responsibly:

• Contact us via the contact form with a description and steps to reproduce.
• Do not test against live data or perform actions that could degrade service.
• No bug bounty program is currently offered, but we appreciate coordinated disclosure.

Questions

Questions about our security posture? Reach us through the contact form or the “Email Us” link in the footer.