Security

Security isn’t a feature—it's a baseline.

Cinteli ships websites with hardened defaults: modern TLS, secure headers, least-privilege access, and edge protections that reduce attack surface and improve resiliency. No buzzwords—real controls, measurable outcomes, and transparent tradeoffs.

Transport

TLS 1.2+ / 1.3

Modern ciphers, HTTPS redirects, OCSP stapling where supported.

Browser Hardening

Security Headers

CSP, HSTS, frame, MIME sniffing, referrer, and permissions controls.

Edge

WAF + Rate Limits

Bot mitigation, L7 rules, throttling, and abuse detection hooks.

Threat model TLS + HTTPS Security headers Edge protections Application hardening Data protection Monitoring & response FAQ

Start with a threat model, not a checklist

“Web security” means different things depending on what you’re protecting. A static marketing site has a different risk profile than a web app that handles authentication, payments, or PII. We model risk by identifying assets (what matters), entry points (where attackers can touch), trust boundaries (where data crosses systems), and realistic adversaries (opportunistic scanning vs. targeted abuse).

Common attack classes

Automated reconnaissance and vulnerability scanning (mass internet noise).
Credential stuffing and brute-force attempts against login surfaces.
Injection and deserialization risks (where applicable) and unsafe template rendering.
XSS/CSRF/session fixation and client-side trust mistakes.
Misconfiguration: permissive CORS, wildcard origins, public buckets, over-broad IAM.

Security posture goals

Minimize attack surface with secure defaults and tight headers.
Reduce blast radius with least privilege and isolated environments.
Detect and respond with logging, alerting, and incident runbooks.
Prefer defense-in-depth over single control “silver bullets.”

Practical note

Security is risk reduction, not a promise of invulnerability. The goal is to make exploitation meaningfully harder, decrease impact if something breaks, and shorten time-to-detect and time-to-recover.

TLS + HTTPS: modern transport guarantees

HTTPS is table stakes, but the details matter: protocol versions, cipher suites, redirect behavior, certificate automation, and how browsers remember security policies. Cinteli’s baseline is to enforce HTTPS, prefer TLS 1.3 when available, and avoid legacy crypto that increases downgrade and interception risk.

Transport controls we implement

HTTP → HTTPS redirect (canonical host) and consistent URL normalization.
Modern TLS configuration (disable weak ciphers; avoid deprecated protocol versions).
Certificate lifecycle automation (renewals, chain correctness, and safe rotation).
Strict-Transport-Security (HSTS) with appropriate max-age and preload guidance.

Why this matters

Prevents passive network interception (e.g., hostile Wi-Fi, ISP injection).
Reduces active man-in-the-middle feasibility and downgrade vectors.
Protects cookie confidentiality and integrity in transit.
Enables modern browser features that require secure contexts.

# Example logic (conceptual)
# 1) Force HTTPS
# 2) Force canonical host (www or apex)
# 3) Preserve path + query

if scheme == "http": redirect("https://{host}{path}?{query}", 301)
if host != CANONICAL_HOST: redirect("https://{CANONICAL_HOST}{path}?{query}", 301)

Implementation details depend on your stack (CloudFront behaviors, reverse proxies, app frameworks), but the objective is consistent: a single secure canonical origin for every request.

Security headers: turn browsers into a security layer

Security headers provide browser-enforced constraints that reduce XSS risk, limit clickjacking, prevent MIME sniffing surprises, and define what the page is allowed to load or do. Properly configured headers shrink the exploit window even when a bug slips through.

Header	Purpose	What we focus on
Content-Security-Policy	Restricts where scripts, styles, images, fonts, and frames can load from.	Default-deny posture, minimize wildcards, reduce unsafe-inline, use nonces/hashes where feasible.
Strict-Transport-Security	Forces browsers to use HTTPS for the domain for a defined period.	Right-sized max-age, includeSubDomains where appropriate, optional preload guidance.
X-Frame-Options / frame-ancestors	Mitigates clickjacking by controlling who can embed the site.	Prefer CSP frame-ancestors with explicit allowlists.
X-Content-Type-Options	Prevents MIME sniffing that can turn benign content into executable content.	Use nosniff, ensure correct content types on assets.
Referrer-Policy	Controls how much URL/referrer data is shared cross-site.	Reduce leakage (paths/tokens) while keeping analytics workable.
Permissions-Policy	Restricts access to powerful browser APIs.	Disable what you don’t need (camera, mic, geolocation, etc.).

# Example header set (baseline, tune per site)
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; frame-ancestors 'none'

CSP is not “set it and forget it.” We treat it like a policy with change control: add sources intentionally, document why, and keep it tight as your site evolves.

Edge protections: absorb noise before it reaches your origin

Most attacks aren’t cinematic— they’re automated. The internet is full of scanners, bots, and abusive clients probing for weak endpoints. Edge controls help stop that traffic early and reduce the chance that a sudden spike becomes downtime.

WAF and managed rules

We use Web Application Firewall rules as a pragmatic layer to block known-bad patterns: common injection payloads, suspicious request anomalies, and high-confidence malicious signatures. WAF isn’t a substitute for secure code, but it can buy time and reduce opportunistic compromise attempts.

Managed rule sets + custom rules for your specific routes.
Explicit allowlists for admin paths where appropriate.
Logging for blocked requests to improve tuning and reduce false positives.

Rate limiting and abuse controls

Rate limits reduce brute-force and scraping risk and protect origin resources. Where applicable, we separate policies by route (e.g., stricter on login and form submission endpoints) and use client fingerprints carefully to avoid punishing legitimate users.

Per-IP/per-token thresholds with sensible burst + sustained limits.
Bot mitigation hooks and challenge flows where supported.
Cache strategy to reduce origin dependency under load.

DDoS reality

You can’t “prevent” all denial-of-service attempts, but you can design for resilience: caching, edge termination, origin shielding, and observability that tells you what’s happening quickly.

Application hardening: reduce attack surface and logic flaws

When your site includes forms, authentication, APIs, or dynamic content, the threat model shifts. This is where OWASP-style issues show up: injection, broken access control, security misconfiguration, and insecure design. Our approach is to implement secure-by-default patterns and enforce constraints at multiple layers.

Identity, sessions, and cookies

Secure cookie attributes: HttpOnly, Secure, and appropriate SameSite.
Short-lived sessions with rotation where applicable.
CSRF protections for state-changing requests (tokens or same-site strategies depending on architecture).
Explicit authorization checks (don’t trust UI state; enforce on the server).

Input handling and output safety

Server-side validation (type, length, allowlists) and sane error responses.
Output encoding to prevent XSS; avoid unsafe HTML injection patterns.
Safe file upload constraints (MIME validation, size limits, and storage isolation).
Dependency hygiene: avoid unpinned supply-chain drift where practical.

Secure deployment patterns

Principle of least privilege for IAM, keys, and roles.
Separate environments (dev/stage/prod) to reduce blast radius.
Non-public origins where feasible (e.g., restrict direct origin access behind the CDN).
Logging + audit trails for administrative changes and access events.

Client-side integrity and third parties

Minimize third-party scripts; treat them as code execution with supply-chain risk.
Subresource Integrity (SRI) when loading static third-party assets via CDN.
Scoped permissions via CSP; remove broad * allowances.
Explicit CORS design (avoid permissive origins and credential leakage).

# Example cookie attributes (conceptual)
Set-Cookie: session=...; Path=/; HttpOnly; Secure; SameSite=Lax

Data protection: confidentiality, integrity, availability

Even “simple” sites often handle sensitive data: contact forms, customer messages, appointment details, or business operations. We focus on minimizing what you collect, encrypting what you must store, and limiting who and what can access it.

Minimization and retention

The safest data is the data you never collect. We design forms to capture only what’s necessary, and we define retention windows so data doesn’t live forever by default.

Reduce PII collection and avoid sensitive fields unless needed.
Document retention and deletion expectations for operational data.
Separate analytics identifiers from user-submitted content where possible.

Encryption and access controls

Encryption is only useful with correct key management and least-privilege access. We combine encryption-at-rest options with strict access controls so that accidental exposure is less likely and compromise impact is limited.

Encryption in transit (TLS) everywhere, including internal hops where applicable.
Encryption at rest for stored content where supported by the platform.
Role separation and audited access for administrative workflows.

Compliance note

Controls can support compliance goals, but “compliance” depends on your business context (data types, geography, industry). We can align architecture and policies to your requirements, but compliance is a program—not a header setting.

Monitoring, logging, and incident response

Security controls are stronger when you can see what’s happening. We prioritize actionable observability: access logs at the edge, origin logs where relevant, alerting thresholds that catch anomalies, and a clear playbook for response.

What we log

Edge access logs (status codes, paths, response times, request metadata).
WAF events (blocked/challenged requests) for tuning and threat visibility.
Administrative changes and configuration events where supported.
Error budgets: monitor 4xx/5xx trends and latency spikes.

How we respond

Triage: identify scope and whether it’s availability vs. integrity vs. data exposure risk.
Containment: tighten rules, rotate credentials, isolate components if needed.
Eradication: fix root cause (configuration, dependency, code path).
Recovery: validate and restore normal operations, then write a post-incident summary.

Want your site hardened?

We can scope a baseline hardening package (headers, TLS, edge controls) or a deeper program (auth, APIs, logging, and policy design).

View Services

Security FAQ

Straight answers to common questions. If you have specific requirements (HIPAA, PCI, SOC 2), we’ll align the architecture and documentation accordingly.

1 Is HTTPS enough?

HTTPS is necessary but not sufficient. Transport security protects data in transit, but it doesn’t fix XSS, broken access control, supply-chain risks from third-party scripts, or misconfigured storage. You want layered controls: TLS + headers + edge protection + secure coding and least-privilege infrastructure.

2 What’s the point of a CSP?

CSP restricts where the browser is allowed to load scripts and other resources. If an XSS bug exists, CSP can stop injected script execution or force it into a constrained sandbox. CSP also acts as documentation: it makes third-party dependencies explicit.

3 Will a WAF block all attacks?

No. A WAF is a valuable mitigation layer for commodity attacks and noisy scanners, but it can’t prove your business logic is correct. We treat WAF as defense-in-depth: it reduces exposure and buys time, while secure app design and proper authorization do the heavy lifting.

4 Can you “guarantee” the site can’t be hacked?

No honest provider can guarantee that. Security is continuous risk reduction: harden, monitor, update, and respond. The goal is to minimize attack surface, limit blast radius, and detect issues quickly.

5 Do you handle vulnerability scanning and patching?

For static sites, the focus is configuration and dependency hygiene (build tooling, third-party scripts, and deployment controls). For app stacks, we can implement a process for dependency updates, review gates, and periodic scans depending on your environment and budget.

6 What about forms and spam?

We mitigate abuse through rate limiting, validation, bot controls (where appropriate), and safe handling of user input. We also recommend minimizing stored form data and routing submissions through controlled services rather than exposing direct endpoints.

If you want a security review of an existing site, we can provide a prioritized remediation list: high-impact misconfigurations first, then deeper improvements (CSP tightening, auth flows, endpoint segmentation, and monitoring).