Ruthless.

Novice · Security basics · 6 min read

Ask Ruthless to help check your own app’s security

Learn what a security test means, prepare fake accounts and use Ruthless to turn one privacy rule into a check you can understand.

← All guidesNovice guidesBy Ruthless AI team

Learn by using GetRuthless

Keep this guide beside your Ruthless chat. Copy one prompt, add the example it asks for and paste it into “Message Ruthless”. Nothing is sent until you choose to send it.

Open Ruthless in another tab ↗More in Security without the jargonNew to this? Start here

The short answer

Start with one rule, such as “customers can only open their own notes”. Give Ruthless a plain description and redacted evidence, ask for a small check, then have your builder run it on a private copy with fake users. A suggested weakness becomes a confirmed problem only when the forbidden action actually works.

Understand what you are checking

A pentest is an authorised attempt to find ways around an app’s protections. You do not need to begin with attack software. Begin with what someone must never be able to do. For a gardening appointment app, that might mean seeing another customer’s address or changing another customer’s booking. The wider OWASP testing guide describes many kinds of checks; this lesson covers one small starting point. [1]

The frontend is the screen and code delivered to a person’s browser. The backend is the service that processes requests and retrieves saved information. Hiding another customer’s booking button on the frontend does not establish that the backend refuses their booking. Ruthless can explain these pieces from material you supply; opening chat does not give it access to your app.

Prepare a safe example you can describe

Ask your builder for a private test copy of your app, separate from real customers. Developers often call this staging. Give it fake accounts A and B, a fake booking for each, and no real payment credentials. Write the expected rule before checking anything: A can see A’s booking, B can see B’s booking, and neither can see the other’s address.

Bring a short description to GetRuthless. If code is needed, ask your builder for the part that opens a booking and the part that checks its owner, with passwords, keys, login cookies and personal information removed. A login cookie is a small browser value that can prove someone is signed in; never share its value.

  1. Visit getruthless.io, sign in if needed and open chat.
  2. Open Choose model, inspect the available options and select a model suited to this explanation task.
  3. Paste the example below into Message Ruthless, adjust the fictional details to your own app and press Send.
Try this prompt
I own a gardening booking app. In our private test copy, fake account A owns booking A-101, with address FAKE-ROSE. Fake account B owns booking B-202, with address FAKE-OAK. Customers must only see their own bookings. Explain the screen, service and saved-data parts in ordinary language. Give my builder one safe check using only these two records, the expected result and what evidence to return. Ask for redacted code if you cannot identify the permission check. Do not claim you visited or tested my app.

Recognise an answer you can act on

A useful answer says: “First confirm A can open A-101. Then, while signed in as A, ask the service for B-202. The response must not contain FAKE-OAK. Ask B to reopen B-202 afterwards and confirm it is unchanged.” If the request is unfamiliar, your builder performs it and brings back a plain explanation of the result.

“Your app probably has broken permissions” is a suspicion, not evidence. A meaningful return is: “On the private copy, A received access denied, no address was returned, and B’s booking was unchanged.” If A received FAKE-OAK, preserve that result and repair the permission rule before repeating the same check. Also repeat the allowed A-to-A case.

Try one rule, then keep the evidence

Your exercise is to write a second rule for your own app and ask Ruthless to turn it into an observable check. For example, cancelling one fake booking must not cancel another. Keep the expected rule, actual result and any unanswered question together. A successful check proves that case in that environment; it does not certify the whole app. Ask a security specialist about deeper testing when the app handles sensitive information or money.

Common questions

Can Ruthless scan my app just from its name?

No. This chat lesson works from context you provide. Your builder runs the checks and returns redacted evidence.

Can I use real customer accounts?

Use a private copy with fake accounts for this exercise. Real customers and real payments are unnecessary to check this rule.

Sources & further reading

  1. OWASP Web Security Testing Guide

The example prompts and workflows are GetRuthless guidance. Source references support the concepts explained; they are not an endorsement of GetRuthless.

Put the guide into practice.

Open Ruthless and choose an available standard or abliterated model suited to your task. Copy a prompt above, add the context it asks for and check the result. You can compare models in the same workspace; see current pricing before sending requests.