Security & Service Disclaimers

This page explains, plainly, what ShieldIngress does and does not guarantee, where responsibility is shared between us and you, and what data we handle and how. It's written for transparency, not to bury anything in fine print.

🛡️1. Security & Liability Boundaries

No guarantee of absolute security

No web application firewall blocks 100% of attacks, and ShieldIngress makes no such claim. The service is a defense-in-depth layer designed to mitigate common and known attack patterns (the OWASP Top 10 and related classes of abuse) — not a guarantee against every zero-day vulnerability, business-logic flaw specific to your application, or a determined, targeted attacker.

Shared responsibility

You remain solely responsible for:

• Patching vulnerabilities in your own application code and dependencies.
• Securing your origin server itself (OS patching, unnecessary services, etc.).
• Managing user accounts, credentials, and access control within your own application.
• Application-level code security generally — ShieldIngress inspects traffic, it does not review or secure your codebase.

Direct-to-origin risk

If your origin server's real IP address becomes known to an attacker, they can potentially bypass ShieldIngress entirely by connecting to it directly. You are responsible for restricting your origin server's ingress traffic to trusted sources — for example, via your own firewall or cloud security group rules. ShieldIngress does not currently publish a fixed set of edge IP ranges for this purpose; if that matters for your setup, contact us to discuss your options.

⚠️2. Traffic Handling & False Positives

False positives happen

WAF inspection rules (including the OWASP Core Rule Set, which ShieldIngress uses as its baseline rule set) can occasionally misidentify legitimate traffic as an attack. You are responsible for monitoring your domain's WAF events, reporting false positives, and configuring exclusion rules or adjusting the paranoia level as needed. See your dashboard's WAF & Security tab and Analytics for the tools to do this.

No automatic floor against traffic spikes

Rate limiting and bot-challenge protection on ShieldIngress are opt-in, per-domain features you configure yourself — there is no platform-wide automatic mitigation applied to every domain by default. A domain with no rate-limit rules configured has no automatic protection against a request flood. Conversely, a rule configured too strictly can block legitimate visitors, including during a genuine attack you're actively trying to mitigate. ShieldIngress is not liable for business loss or downtime resulting from either an unconfigured domain being overwhelmed, or a self-configured rule blocking legitimate traffic.

🔒3. SSL/TLS & Data Inspection Limitations

TLS termination scope

SSL/TLS connections from your visitors are decrypted at ShieldIngress's edge in order to evaluate HTTP headers, parameters, and request content against WAF rules, before being re-encrypted (or sent as configured) to your origin server. This is a standard part of how any reverse-proxy WAF operates, and is required for the WAF to inspect anything at all.

Request bodies are inspected, not stored

Unlike some simpler proxy setups, ShieldIngress's WAF engine does inspect request body content — including POST form data, JSON/XML payloads, and file uploads — against its rule set by default, as part of detecting SQL injection, XSS, and similar attack patterns. What it does not do is persistently store or log that body content: access and traffic logs (see §4) capture request metadata like method, path, and status code, never the body itself.

Certificate management

ShieldIngress currently issues and renews SSL certificates for your domains automatically via Let's Encrypt — there is no customer-uploaded certificate option today. Automatic renewal depends on your domain's DNS or HTTP-01 validation method remaining intact and reachable; if that validation path breaks (e.g. you change DNS providers or move the site handling the HTTP-01 challenge path), certificate renewal can fail, which would ultimately cause an outage for that domain. Keeping your DNS records pointed correctly is your responsibility.

📋4. Logging, Privacy & Regulatory Compliance

Short retention window

Access/traffic logs and WAF event logs are retained for a rolling 14 days and are then permanently purged. If you need a longer-term audit trail, you're responsible for exporting what you need within that window — ShieldIngress does not currently offer an automated external log-streaming (syslog/SIEM) integration.

What's captured, and what isn't anonymized

Traffic logs capture, per request: source IP address, HTTP method, request path, response status code, response time, bytes transferred, User-Agent, and (when resolvable) country of origin. WAF event logs additionally capture the specific rule that matched and its severity. Source IP addresses are stored in raw, unredacted form — they are not hashed or anonymized. Avoid passing sensitive data — passwords, personal information, credit card numbers — in URL query strings or parameters, since those are captured in logs like any other request data.

Regulatory compliance scope

ShieldIngress is not currently certified under PCI-DSS, HIPAA, or any formal GDPR compliance program. Because TLS is terminated at our edge and request metadata (including IP addresses, which are personal data under regulations like GDPR) is logged, ShieldIngress does function as a data processor for traffic that flows through it — but this page is not a Data Processing Agreement, and none is currently offered as a standard document. If your organization has specific regulatory requirements (PCI-DSS, HIPAA, GDPR, or otherwise), you are responsible for evaluating whether ShieldIngress meets them for your use case, and should contact us directly to discuss your requirements.

📶5. Availability, Performance & Bandwidth

Latency overhead

Routing traffic through ShieldIngress's edge adds a small amount of network latency — typically low, single-digit milliseconds — for TLS negotiation and WAF inspection, on top of whatever latency already exists between your visitors and your origin server.

Bandwidth & traffic spikes

Each plan lists indicative monthly request and bandwidth figures. These are informational fair-use signals, not hard limits — exceeding them does not automatically throttle your traffic or generate an overage charge today. That said, ShieldIngress reserves the right to take action, including rate-limiting or temporarily suspending traffic, in cases where a domain's traffic (whether a legitimate spike, a misconfiguration, or a volumetric attack such as a DDoS) threatens the stability of the shared platform for other tenants. As noted in §2, there is no platform-wide automatic rate limiting applied by default — if you need protection against traffic spikes, configure rate-limit rules for your domain yourself.