Security FAQs

Welcome to the Security FAQs section of the Kingdom Nurturing Suite (KNS). Here, you will find answers to some of the most common questions about security practices and features in KNS. If you have any other questions, please feel free to reach out to our support team.

No. We never display contact details provided in your profile (like phone number or email). The only time contact information is shown is for public events — so that interested parties can get in touch with event organizers.
Not at all. All report data is fully anonymized. No profile information is included, and there’s no way to trace any data back to a specific user.
Only if the group leader allows it. Group leaders can choose to hide member names and instead display anonymous pseudo names, ensuring your privacy within the entire application.
No. Group leaders can only view users in their own subtree — meaning their group and its direct or indirect members. Each user only has access to the data generated from their subtree.
Yes. We continuously add features to limit data exposure, anonymize sensitive info, and give users or group leaders more control over what is visible to others.
We use Cloudflare’s infrastructure to automatically defend against Distributed Denial of Service (DDoS) attacks. These attempts to overwhelm our servers are filtered before they can cause any impact.
Our platform includes a firewall that blocks known malicious traffic and protects against common attacks like SQL injection and cross-site scripting (XSS).
Yes, development, staging, and production environments are completely isolated from one another to ensure operational safety and prevent cross-contamination of data or access.
Yes, all data sent to and from our servers is encrypted using TLS 1.2 or higher, protecting sensitive information from being intercepted.
Private networking ensures internal services (like databases and APIs) communicate over secure, internal channels rather than the public internet, reducing exposure.
Yes, data including backups and stored files are encrypted at rest using AES-128 or higher encryption standards.
Render is ISO 27001 certified and supports HIPAA-enabled workspaces, which means it adheres to rigorous international security standards.
We use BetterStack to monitor logs and events in real-time, giving us immediate visibility into suspicious activity or system issues.
Django automatically escapes user-submitted content before it’s rendered, preventing malicious scripts from being executed in the browser.
Every form includes a CSRF token which ensures the request came from the actual user, preventing attackers from tricking your browser into submitting unintended requests.
Django uses parameterized queries under the hood, safely separating logic from user data so attackers can't insert harmful SQL commands.
Django prevents our site from being embedded in iframes, protecting you from fake interfaces that trick you into clicking harmful elements.
Yes, we use HTTPS and secure cookies to encrypt data in transit and protect your session data from being exposed or hijacked.
Django verifies incoming requests are from approved hosts, blocking spoofed requests that could target internal services.
We disable debug mode, define allowed hosts, store sensitive data in environment variables, and enforce secure cookie policies in production.
CSP lets us control which resources (like scripts and styles) can run in your browser. It helps block unauthorized scripts even if they are injected.
Yes, we use Bandit to audit our code and Safety to check for known vulnerabilities in dependencies. This helps us fix problems early.
We implement rate limiting and throttling to cap how often users (or bots) can make requests. This helps defend against abuse and attacks.
Yes. We only allow specific file types, scan uploads for malware (where needed), and store them in directories that cannot be directly accessed.
We use a hidden URL, require strong passwords and two-factor authentication (2FA), and restrict access based on roles and sometimes IP address.
Users see a clean error page, while we securely log full technical details in the background so we can fix the issue without exposing internals.
Secrets like API keys and database passwords are stored in secure `.env` files, never in code. We use libraries like `django-environ` to manage them.
We pin exact versions of all packages, upgrade cautiously, and use Dependabot to get alerts when a vulnerability is discovered.
We use tools like BetterStack and Sentry to monitor production behavior. They notify us instantly about crashes, errors, or potential security issues.
We use account lockout mechanisms that temporarily block login after a certain number of failed attempts. This helps protect against brute-force attacks. You’ll be notified if your account is locked, and options are provided to safely reset your password.
Passwords are never stored in plain text. We use strong one-way hashing algorithms like Argon2 or bcrypt, which are designed to be slow and computationally expensive — making brute-force attacks impractical.
Web apps provide centralized control, so fixes and updates are deployed immediately without requiring users to download anything. This makes patching faster and more reliable.
Unlike mobile apps, web platforms don’t have access to native device APIs like camera, storage, or GPS — which significantly reduces the possible attack surface.
You only need to audit the backend codebase and frontend UI — no need to maintain separate code or security practices across multiple platforms like iOS and Android.
Yes. Since there’s no app store submission or bundled third-party SDKs, there’s a lower chance of supply chain attacks like malicious SDK injections or approval bypasses.