Security Policy

Objectives and scope

Seoptiz aims to protect account access, limit the effects of untrusted input, restrict outbound requests to public destinations, and preserve the integrity of stored projects and site content. Security depends on application code, deployment configuration, database access, mail delivery, dependencies, and operating procedures. This policy covers the Seoptiz website and its diagnostics features; it does not authorize testing of infrastructure owned by a hosting, database, email, DNS, or advertising provider.

No security certification, independent penetration test, formal bug-bounty program, or service-level commitment is claimed by this page. A control described here is a risk-reduction measure, not a guarantee that the service is free of vulnerabilities.

Account and administrative access

Passwords are processed with a password-hashing function rather than stored as readable text. Email verification and password-reset links use random, time-limited tokens; the database stores token hashes and the token purpose. Sign-in regenerates the session, and administrative routes check for an administrator role. Account features require a database and, for verification-dependent paths, an email-verification record.

Session cookies are configured HttpOnly and SameSite=Lax, with a twelve-hour maximum age. The Secure flag depends on production configuration and HTTPS. Database-backed sessions are used only when a database is configured; the in-memory fallback is not a durable production session store. Operators must set a stable session secret and verify proxy, TLS, and cookie settings before production use.

State-changing forms use CSRF validation. Rate limits apply to relevant tool and administrator actions. These checks can be weakened by a misconfigured deployment or an undiscovered defect, so users should still protect passwords and verification messages.

Input handling and outbound request controls

The application validates input formats, encodes output in templates, sanitizes CMS content, and restricts website fetches to HTTP or HTTPS public destinations. Fetch logic validates DNS answers, checks redirects, enforces a request timeout and response-size cap, and avoids private, reserved, loopback, link-local, and other special-use addresses. These controls are designed to reduce server-side request forgery and resource-exhaustion risk.

Those safeguards are not a statement that every edge case, address translation, provider behavior, or future tool is covered. The current multi-page crawler is disabled; the service does not expose a general port scanner or exploit testing interface. A new outbound integration must be reviewed separately and must preserve target restrictions, timeouts, response bounds, and rate controls.

Data, secrets, and logging

Database records can include account information, project domains, audit results, tool-use timestamps, administrator actions, and CMS content. Password reset tokens are stored as hashes. SMTP credentials and session secrets are expected from server-side environment configuration and must never be placed in browser code, public settings, source archives, or logs. The administrator panel does not return SMTP secrets.

The application does not currently store anonymous visitor IP addresses or country/region in its own database. Hosting and network providers may produce request logs under their own policies; the service operator must establish the provider, access restrictions, and retention practices. Database backups and infrastructure logs may outlive records removed from the active application tables.

Administrator actions are recorded in an audit log when the database is enabled. The application does not claim continuous security monitoring, an intrusion-detection service, a 24-hour operations team, or a fixed retention period for all logs.

Development, dependencies, and maintenance

Security should be considered when adding a tool, changing an outbound request, updating authentication, or connecting a new provider. The current application includes input checks, output encoding, sanitization for managed content, dependency-based security controls, and automated build and test commands. These measures do not establish a formal secure-development certification, a fixed code-review schedule, continuous dependency monitoring, or a guaranteed patch window. The operator must review dependency advisories, apply supported updates, test changes, and remove abandoned components as part of operating the service.

New integrations should be reviewed for what data they receive, what credentials they require, how their responses are validated, how failures are handled, and whether they introduce new browser scripts or cookies. New outbound fetches should be assessed for destination validation, DNS changes, redirects, timeouts, response-size bounds, and abuse limits. A feature must not be considered safe solely because similar code exists elsewhere in the project.

Operators should keep source code, runtime packages, database software, and infrastructure components on supported versions; limit administrative access; use separate development and production settings; and avoid copying production personal data into tests. The application does not claim that every deployment performs these operational steps automatically.

Deployment configuration and administrator duties

Security settings depend on the production environment. The operator must serve account pages over HTTPS, configure trusted proxy handling carefully, enable secure session cookies, set a strong unique session secret, protect database credentials, and restrict database network access. SMTP credentials should be stored in server-side secret storage and must never be included in browser JavaScript, public CMS content, a URL, or a public source archive. The admin page intentionally does not reveal SMTP passwords.

Administrator accounts should use unique credentials and be granted only to people who need those privileges. Remove access when a person no longer needs it, review administrator changes, and avoid sharing a single administrator account. An administrator who changes tool visibility, access levels, website content, or ads can affect users and should review the change before saving it.

Database connectivity, email sending, cookie security, backups, log access, content security, domain ownership, and DNS are deployment choices. The application cannot verify every setting from its own page. A successful development build or health check does not establish that production is configured securely.

Suspected incidents and response limitations

If an operator suspects that credentials, account data, or a server has been compromised, the first priorities are to limit ongoing access, preserve relevant evidence, protect affected users, and restore trusted operation. Appropriate actions may include disabling a credential, restricting an account, rotating secrets, pausing a risky integration, isolating an affected system, or asking a provider for assistance. The response must avoid destroying evidence needed to understand the incident.

Notification duties depend on the facts, affected information, location of individuals, role of each provider, and applicable law. The application does not provide an automated breach-notification workflow, incident hotline, or fixed notification clock. The operator must investigate promptly, determine the applicable legal obligations with qualified counsel, notify affected people or authorities when required, and keep records of decisions.

Users who suspect their account is compromised should stop using the affected session, change the password from a trusted device, and contact the operator through a verified channel. Do not send the old password, a one-time reset link, or an unredacted cookie. The current contact page states whether a public channel has been verified; no address should be assumed active until it is listed there.

Monitoring, backups, and operational recovery

The application records some administrator changes and may record tool usage and authentication events in its configured database. Such records can help investigate an issue but are not equivalent to continuous monitoring or a security operations center. Hosting, database, or network providers may maintain separate logs. Access to logs should be limited, and the operator should define retention and deletion periods rather than retain logs indefinitely.

The application does not claim that production backups are enabled, encrypted, or tested. Before account data is stored in production, the operator should establish a backup schedule, restrict who can restore or download backups, protect backup credentials, define retention, and test recovery in a safe environment. A backup can contain records removed from the active database; users should not be promised immediate deletion from every copy unless the process supports it.

Availability depends on the application host, database, DNS, mail provider, and external sources. A tool failure can be a dependency outage rather than a security event. The operator should distinguish these cases and avoid exposing secrets or personal data in diagnostic messages.

Report triage and information handling

A vulnerability report should include the affected page or feature, the behavior observed, a concise explanation of impact, a minimal reproduction using only the researcher's own account or data, the approximate time, and any relevant browser or environment detail. Screenshots, request snippets, or a short video can help, but remove cookies, authorization headers, personal information, and unrelated third-party content first.

Do not send a full working exploit, stolen data, unredacted authentication link, production secret, or sample containing another person's information unless a verified security contact specifically requests a safe and necessary artifact. If a report requires an attachment, use a verified channel and agree on a safe method. No PGP key or secure upload facility is currently published.

When a report arrives through a verified channel, the operator should limit access to people needed for triage, keep the report separate from public CMS content, record relevant decisions, and delete unneeded copies. The reporter should not assume that a public contact page is a secure disclosure channel unless it says so.

Account, data, and administrator protection

Users should use a unique password, keep verification and reset links private, sign out on shared devices, and report unexpected account activity. The application requires email verification for account features that depend on verified addresses, but email delivery is not operational until a provider is configured and tested. Do not assume that an account is protected by multi-factor authentication; this release does not claim an active MFA flow.

Administrators should restrict privileged accounts, remove stale access, protect server-side secrets, and review changes made to tools, users, ads, and content. A database-backed audit log can help reconstruct administrator actions but is not a guarantee that every relevant event is recorded or retained. The operator should not expose logs or admin screens to unauthenticated visitors.

When a feature stores user reports, the operator should confirm database permissions, backup controls, retention, deletion behavior, and recovery before inviting users to rely on it. Seoptiz does not claim end-to-end encryption of report content or that every provider is unable to see it. Users should avoid including sensitive material in reports and tool inputs.

Transport security, backups, and recovery

Production pages should be served over HTTPS. Whether TLS is active and correctly configured depends on the deployment and its proxy or hosting layer; this page cannot certify that configuration. The operator should set secure cookies, protect database connections, limit administrative access, and keep secrets out of URLs and logs.

Backups, recovery testing, availability monitoring, and incident communications must be configured by the operator. The application does not claim that every database is backed up or that restoration has been tested. Before storing important account data, establish backup frequency, access controls, encryption practices, retention, and a recovery procedure that can be tested without exposing real user data.

Reporting a suspected vulnerability

Use the Contact Us page to check the current reporting channel. No dedicated security mailbox, PGP key, or intake form is currently verified. Do not send secrets, personal records, full verification links, or destructive proof-of-concept code through an unverified channel. The owner should publish a dedicated contact only after confirming that the mailbox receives messages and that someone can review it.

A useful report should identify the affected public URL or feature, describe the security impact in plain language, provide minimal steps to reproduce, state the date and environment, and include only the evidence needed to demonstrate the issue. Redact account identifiers, tokens, cookies, and third-party personal data. If a vulnerability could expose or alter data, stop testing once the impact is established; do not access records that are not yours, change or delete data, or disrupt availability.

Good-faith research should stay within the public Seoptiz application and avoid third-party systems, denial-of-service tests, social engineering, credential attacks, persistence, or attempts to reach internal infrastructure. There is no promise of safe harbor beyond applicable law, no bounty, and no guaranteed acknowledgment or remediation schedule.

Research boundaries and coordinated disclosure

Only test a public feature that you can access without bypassing authentication, authorization, or a rate limit. Use a test account you control and non-sensitive data. Do not view, modify, or delete another user's information. Do not attempt privilege escalation against real accounts, brute-force passwords, send phishing messages, alter DNS records, disrupt availability, or test a third-party service merely because it is used by Seoptiz.

A report should avoid enabling exploitation while the operator investigates. Do not post a reproduction publicly, publish database contents, or identify affected users. If the operator asks for a reasonable clarification, provide only the minimum additional evidence needed. If the issue affects an external provider, notify that provider through its own security process and stop testing it.

Good-faith reporting does not itself create a contract, guarantee immunity from all claims, or waive any party's legal rights. The owner has not adopted a formal safe-harbor agreement, bug bounty, or vulnerability disclosure program beyond the boundaries stated on this page. Researchers should obtain legal advice if uncertain about their planned testing.

Policy review and practical expectations

This policy is a public summary, not a complete system design or promise that every listed control is enabled in every environment. The application can be configured differently by an operator, and infrastructure can change. Owners should review the deployed code and configuration before making security claims, update this page after material changes, and promptly correct statements that no longer match the service.

Security expectations should be proportionate to the data and feature. A public single-page check has different risk from an account dashboard storing projects and audits. If the operator adds a public API, file storage, billing, analytics, or a new identity provider, the scope of risk and disclosure must be reassessed. Users should read the tool's own limitations and avoid relying on a high-level policy as proof of safety.

Triage, remediation, and disclosure

The operator should acknowledge a report when a verified intake channel and operational capacity are available, reproduce it safely, assess severity and scope, and take reasonable steps to fix or mitigate a confirmed issue. Timelines depend on severity, reproducibility, available resources, and dependencies; no fixed response or remediation time is promised.

Researchers should allow reasonable time for investigation and coordinate public disclosure where practical. The operator may ask for clarification or a safe reproduction. The researcher should not disclose personal data, credentials, or details that would enable exploitation before coordination. If a report concerns a third-party service, contact that service's security team and do not test beyond the researcher's authorization.

Third parties, exclusions, and updates

Public websites, DNS resolvers, RDAP registries, mail providers, and any optional advertising service are operated independently. Their security controls and incident timelines are outside Seoptiz's control. A Seoptiz check is not a substitute for a security assessment of those providers.

Testing of user accounts, third-party hosting, production infrastructure outside the public application, or any service without authorization is excluded. The policy may change as controls and contact channels change. Review the Acceptable Use Policy, Privacy Policy, and Terms of Service for related requirements.

Security contact

Until a dedicated mailbox or reporting channel is verified, no security email address is published. Use the Contact Us page to see the current status. Before this policy is relied on for production, the site owner should confirm a staffed security contact and review this procedure with qualified counsel.