Security
How Newtools protects accounts, product data, and the systems behind the tools directory.
Last updated: · Newtools, Sydney, Australia
We take the security of Newtools seriously. This page is a public overview of how we protect accounts, directory data, and product features — written for customers and researchers, not as a sales brochure full of unverified claims.
Related: Privacy Policy · Terms of Service
Contact / reports: support@newtools.io
Honest scope
No web product is perfectly secure. We use sensible industry practices, fail closed on sensitive paths where we design them that way, and fix issues when we learn about them. If you find a vulnerability, please tell us privately first.
1. What we protect
Depending on how you use Newtools, this can include:
- Account data — email, auth credentials (stored as secure hashes, not plain passwords), sessions, passkeys, 2FA settings
- Product data — bookmarks, settings, submissions, admin audit trails where applicable
- AI activity — prompts and chat history when you use the assistant (see Privacy for retention and processors)
- Directory operations — listing metadata, outbound click analytics, moderation workflows
- Secrets — API keys and service credentials used by our infrastructure (never meant to appear in public pages)
We do not store full payment card numbers. Card data is handled by our payment provider when paid features are used.
2. Encryption and transport
- In transit: Newtools is served over HTTPS / TLS. Browsers should show a secure connection on production.
- At rest: Primary application data lives in a managed Postgres database (Neon) with provider-side encryption at rest.
- Secrets: Service credentials and sensitive configuration are kept in environment configuration on the host platform — not committed to public source for production keys.
- Tokens: Where the product stores third-party access tokens for integrations, the design intent is encrypted storage and use only for actions you request (see Privacy).
3. Infrastructure
| Layer | How we run it |
|---|---|
| Application | Hosted on Vercel (Next.js App Router) |
| Database | Neon Postgres — source of truth for product data |
| Resend for transactional mail (magic links, notices) | |
| Payments | Stripe when paid features are enabled (card data stays with Stripe) |
| AI | Model inference via configured AI providers / gateway — prompts sent only to generate responses |
We prefer managed providers so that patching, network isolation, and physical security of the metal are handled by specialised platforms. Application security (auth, authorisation, input handling) remains our responsibility.
4. Authentication and account security
Newtools uses Better Auth with modern account controls, including:
- email/password with hashed passwords
- magic link sign-in where enabled
- passkeys
- two-factor authentication (2FA) where enabled
- session management and account security settings in the signed-in product
Your responsibilities
- Use a unique, strong password or a passkey
- Enable 2FA when available
- Keep devices and browsers updated
- Tell us if you suspect unauthorised access: support@newtools.io
Our responsibilities
- Privileged admin actions re-check roles on the server — UI flags never decide alone what is allowed
- Sensitive modules are marked server-only so secrets and privileged logic are not bundled into the browser
- Auth cookies and session handling follow the auth stack’s secure defaults for the deployment environment
5. Authorisation and admin access
- Public directory queries are designed not to expose admin-only fields (for example internal notes or raw affiliate destinations on public listing APIs).
- Outbound “visit” links may use a dedicated redirect so affiliate URLs are not the crawlable identity of a tool page.
- Manage / admin surfaces require authenticated roles; destructive or privileged writes are server-validated.
6. Application safeguards
Practices we invest in as the product grows:
| Area | Approach |
|---|---|
| Rate limiting | Durable limits on sensitive AI and abuse-prone endpoints (fail closed where designed that way) |
| Outbound / fetch safety | Listing intelligence fetches are constrained (including SSRF-aware design for URL ingestion) |
| Honest failure modes | Email and logging helpers avoid claiming success when a side effect did not happen |
| Input handling | Server validation on privileged forms and APIs |
| Dependencies | Regular lockfile-based installs; production builds go through typecheck, lint, and tests in our workflow |
We do not publish a full penetration-test report on this page. If you need a questionnaire for enterprise procurement, contact us.
7. AI features
When you use the assistant:
- prompts are processed by third-party model providers to generate a reply
- we select provider modes that do not train on API data where that option exists
- we do not sell your conversations
- rate limits reduce abuse and runaway cost
Do not submit secrets or other people’s personal data into the assistant. See the Privacy Policy for processors and rights.
8. Data access and deletion
You can manage much of your data from account Settings (profile, sessions, passkeys, danger zone / delete account where available).
For access, correction, or deletion requests that the UI does not cover, email support@newtools.io. Legal rights are described in the Privacy Policy.
9. Backups and availability
- Database durability and backups are provided by our database platform’s managed features.
- Application availability depends on our host and upstream providers.
- We aim for continuous operation but do not promise zero downtime (see Terms).
10. What we do not claim on this page
To stay accurate, this overview does not assert:
- a specific SOC 2 / ISO certification number (unless we publish one later)
- that any third-party tool listed in the directory is secure — listings are third-party products
- that AI output is free of error or safe to trust without review
Security of tools you discover on Newtools is the responsibility of those vendors. Use our content as research input, not as a certification.
11. Responsible disclosure
We appreciate researchers who report vulnerabilities privately and in good faith.
Please:
- Email support@newtools.io with a clear description, steps to reproduce, and impact
- Give us a reasonable time to investigate and fix before public disclosure
- Do not access other users’ data, destroy data, or degrade the service beyond what is needed to demonstrate the issue
Please do not:
- run destructive testing against production
- social-engineer our users
- spam, DDoS, or violate applicable law
We will acknowledge reports as promptly as we reasonably can and prioritise by severity.
If you need a dedicated security address later (security@newtools.io), we may publish it here when it is monitored.
12. Changes
We may update this page as the product and infrastructure evolve. The Last updated date at the top will change when we do.
13. Contact
Newtools
Sydney, Australia
Email: support@newtools.io
Web: https://www.newtools.io
For how we use personal information, read the Privacy Policy. For rules of use, read the Terms of Service.