# Abin Antony Security > Independent cybersecurity engineer in Kerala, India: mobile, web, API and cloud penetration testing, secure code review and threat modelling. Operated by Abin Antony, Cybersecurity Engineer & Application Security Consultant, based in Kochi, Kerala, India. Engagements are delivered remotely worldwide and on-site across India. Contact: abina35@gmail.com Full text of every page: https://cs.abinantony.io/llms-full.txt ## Services - [Mobile App Penetration Testing](https://cs.abinantony.io/services/mobile-app-penetration-testing): Mobile app penetration testing is a manual security assessment of an Android or iOS application, its local storage, its runtime and the APIs behind it. Testing follows the OWASP Mobile Application Security Verification Standard and produces a report of exploitable findings, each with reproduction steps and a code-level fix. - [Web Application Penetration Testing](https://cs.abinantony.io/services/web-application-penetration-testing): Web application penetration testing is a manual assessment of a live web application performed with real user accounts, targeting broken access control, injection, authentication weaknesses, SSRF and business-logic abuse. Findings are mapped to OWASP ASVS and delivered with proof-of-concept requests and a specific fix for each issue. - [API Security Testing](https://cs.abinantony.io/services/api-security-testing): API security testing is a manual assessment of REST, GraphQL or gRPC endpoints against the OWASP API Security Top 10. It targets broken object and function level authorisation, mass assignment, excessive data exposure, unrestricted resource consumption and authentication flaws that client-side testing cannot reach. - [Secure Code Review](https://cs.abinantony.io/services/secure-code-review): Secure code review is a manual inspection of source code focused on the paths where security actually fails: authentication, authorisation, payment handling, cryptography, file handling and injection sinks. It is combined with static analysis triage so the output is a short list of confirmed issues with the fix, not thousands of scanner alerts. - [Cloud Security Assessment](https://cs.abinantony.io/services/cloud-security-assessment): A cloud security assessment reviews IAM permissions, network exposure, storage access, secrets management and CI/CD pipeline trust boundaries across AWS, GCP or Azure. Findings are ranked by blast radius — what an attacker reaches after compromising one identity — rather than by a generic benchmark score. - [Threat Modelling & Security Architecture Review](https://cs.abinantony.io/services/threat-modelling): Threat modelling is a structured design review that maps data flows and trust boundaries, enumerates how each component can be abused, and ranks the controls worth building. Done before implementation, it removes whole classes of vulnerability at the cost of a workshop instead of a rewrite. - [Developer Security Training & DevSecOps](https://cs.abinantony.io/services/devsecops-training): Developer security training is a hands-on workshop where a team exploits vulnerabilities in its own application and then fixes them, followed by wiring the matching checks into CI. It replaces annual slide decks with muscle memory, and leaves behind gates tuned to fail only on issues worth blocking a release. ## Answers - [How much does a penetration test cost in India?](https://cs.abinantony.io/answers/how-much-does-a-penetration-test-cost-in-india): A professional penetration test in India typically costs between ₹60,000 and ₹4,00,000 depending on scope. A single web application usually lands at ₹75,000 to ₹1,50,000, a mobile app with its backend at ₹85,000 to ₹2,00,000, and a small cloud environment at ₹70,000 to ₹1,50,000. Price is driven by testable surface, not company size. - [How long does a penetration test take?](https://cs.abinantony.io/answers/how-long-does-a-penetration-test-take): A typical application penetration test takes two to three weeks from kickoff to final report: two to three days of scoping and setup, five to ten days of active testing, three to five days for reporting, and a retest once fixes ship. Larger environments or multiple applications extend the testing phase proportionally. - [What is VAPT?](https://cs.abinantony.io/answers/what-is-vapt): VAPT stands for Vulnerability Assessment and Penetration Testing. The vulnerability assessment is broad and largely automated, listing known weaknesses across a system. The penetration test is narrow and manual, proving which of those weaknesses can actually be exploited and what an attacker reaches through them. Most compliance frameworks expect both. - [What is the difference between a vulnerability scan and a penetration test?](https://cs.abinantony.io/answers/difference-between-vulnerability-scan-and-penetration-test): A vulnerability scan is an automated tool that compares your system against a database of known weaknesses and reports matches. A penetration test is a human attacking your system with the tools plus judgement, proving which weaknesses are exploitable, chaining them, and finding logic flaws that exist in no signature database. - [How often should you run a penetration test?](https://cs.abinantony.io/answers/how-often-should-you-pentest): Test at least once a year, and additionally after any change that alters your attack surface: a new authentication system, a major architecture refactor, a first payment integration, a new public API, or a merger that connects two environments. Products shipping continuously should pair an annual full test with lighter release-time reviews. - [Do startups need a penetration test before launch?](https://cs.abinantony.io/answers/do-startups-need-a-penetration-test-before-launch): A pre-launch penetration test is worth it if your product handles payments, personal data, health or financial records, or user-generated content. If it does not, a threat-modelling session plus a secure code review usually buys more security per rupee at that stage, because there are still few users and the architecture can still change cheaply. - [What is OWASP MASVS?](https://cs.abinantony.io/answers/what-is-owasp-masvs): OWASP MASVS is the Mobile Application Security Verification Standard: a public list of security controls that Android and iOS apps are tested against. It defines what "secure" means for storage, cryptography, authentication, network communication, platform interaction and code quality, at two verification levels plus an optional resilience set. - [Is my Flutter app secure?](https://cs.abinantony.io/answers/is-my-flutter-app-secure): Flutter neither adds nor removes security by itself. The common weaknesses in Flutter apps are the same ones found elsewhere — secrets compiled into the bundle, data stored unencrypted, missing certificate pinning and authorisation enforced only in the UI — but the Dart snapshot changes how easily an attacker recovers logic and strings. - [What does a penetration test report contain?](https://cs.abinantony.io/answers/what-does-a-penetration-test-report-contain): A penetration test report contains an executive summary, the scope and methodology used, a findings section with evidence, reproduction steps and severity ratings, specific remediation guidance for each issue, and a retest record confirming which findings were closed. Anything without reproduction steps and a named methodology is a scanner export. - [How do you fix insecure data storage in an Android app?](https://cs.abinantony.io/answers/how-to-fix-insecure-data-storage-in-android-apps): Fix insecure Android storage by keeping secrets out of the device entirely where possible, storing anything unavoidable in Keystore-backed encrypted storage rather than plain SharedPreferences, excluding sensitive files from auto-backup, disabling verbose logging in release builds, and clearing cached responses and databases on logout. - [What is API security testing?](https://cs.abinantony.io/answers/what-is-api-security-testing): API security testing assesses REST, GraphQL or gRPC endpoints directly, independently of any client application. It targets broken object and function level authorisation, weak token handling, mass assignment, excessive data exposure and missing rate limits — the OWASP API Security Top 10 — using paired accounts to prove cross-account access rather than infer it. - [How do you prepare for a security audit?](https://cs.abinantony.io/answers/how-to-prepare-for-a-security-audit): Prepare for a security audit by inventorying systems, data and third parties; collecting evidence that your existing controls actually run; commissioning an honest gap assessment before the auditor arrives; and having a recent penetration test report with a retest record. Most audit failures are missing evidence, not missing controls. ## Blog - [What the DPDP Act actually asks of a small product team](https://cs.abinantony.io/blog/dpdp-act-for-product-teams): The Act is short, and most of what it asks a product team for is engineering work you can do in a sprint: know what you hold, prove consent, delete on request, notice a breach. - [The mobile app security checklist I run before every release](https://cs.abinantony.io/blog/mobile-app-security-checklist): Twenty checks, grouped the way an attacker looks at an app: what ships inside the package, what lands on the device, what crosses the network, and what the server accepts. - [OWASP Mobile Top 10, translated for Flutter teams](https://cs.abinantony.io/blog/owasp-mobile-top-10-for-flutter-teams): The Top 10 is written platform-agnostically. Here is what each risk looks like in a real Flutter project, and which package choice usually causes it. - [Five API mistakes I find in almost every assessment](https://cs.abinantony.io/blog/api-security-mistakes): Five findings appear so consistently that I now test for them in the first hour of any API engagement. Each has a one-paragraph fix. - [What Indian startups should actually budget for security](https://cs.abinantony.io/blog/security-budget-for-indian-startups): Security spend fails when it arrives in the wrong order. Here is what buys the most risk reduction at each funding stage, with indicative rupee figures. - [Certificate pinning without bricking your app](https://cs.abinantony.io/blog/certificate-pinning-without-breaking-your-app): Pinning fails in one of two ways: not implemented, or implemented so tightly that a routine certificate renewal takes the app offline for everyone who has not updated. - [Broken access control: the bug class that outlives every framework](https://cs.abinantony.io/blog/broken-access-control): Frameworks solved authentication a decade ago. Authorisation is still hand-written per endpoint, which is why the same finding leads report after report. - [JWTs are not sessions: token handling mistakes in mobile backends](https://cs.abinantony.io/blog/jwt-mistakes-in-mobile-backends): A JWT is a signed claim, not a session. Treating it as one produces tokens nobody can revoke and a logout button that logs nobody out. - [The IAM blast radius review, step by step](https://cs.abinantony.io/blog/iam-blast-radius-review): A compliance score tells you which policies are untidy. A blast radius review tells you what happens when one CI key leaks — which is the question you actually need answered. - [How to answer an enterprise security questionnaire without lying](https://cs.abinantony.io/blog/answering-a-security-questionnaire): The instinct is to answer yes to everything and hope nobody checks. Reviewers check, and a caught overclaim costs more than every honest no combined. - [Secrets in git history: finding them before someone else does](https://cs.abinantony.io/blog/secrets-in-git-history): Deleting a key in a later commit does not remove it. The only response that counts is rotation, and the only prevention that works runs before the commit lands. - [The logs you will wish you had after an incident](https://cs.abinantony.io/blog/logs-you-will-want-after-an-incident): During an incident you cannot add logging retroactively. Every question you will be asked depends on events you either recorded beforehand or did not. - [Threat modelling a payments flow in ninety minutes](https://cs.abinantony.io/blog/threat-modelling-a-payments-flow): Threat modelling gets skipped because it sounds like a two-day workshop. Here is the ninety-minute version, run on the flow that carries your money. - [Rate limiting that actually stops OTP abuse](https://cs.abinantony.io/blog/rate-limiting-otp-abuse): A four-digit OTP with a per-IP limit is not protected. It is protected against one attacker on one connection, which is not the attacker you have. - [What a scanner cannot tell you about your Android app](https://cs.abinantony.io/blog/what-a-scanner-misses-in-android-apps): A mobile scanner report reads alarmingly and usually contains nothing severe. Everything severe requires a second account, a device and a person. - [Pentest or code review, when you can only afford one](https://cs.abinantony.io/blog/pentest-or-code-review): They answer different questions. Which one to buy depends on whether you need to know what an attacker can do today, or why it was possible in the first place. - [The password reset flow is your real authentication system](https://cs.abinantony.io/blog/password-reset-flows): Nobody attacks your login form. They attack the flow that issues credentials to whoever holds an email address — which is usually written once and never reviewed. - [A pull request security checklist people actually use](https://cs.abinantony.io/blog/pull-request-security-checklist): A forty-item security checklist gets ticked without being read. Seven questions, asked only when they apply, get answered honestly. ## Blog categories - [Mobile security](https://cs.abinantony.io/blog/category/mobile-security): These posts cover Android and iOS application security as it appears in real assessments: what ships inside the package, what lands on the device, how transport protections are bypassed, and why the backing API is usually where the severe findings actually are. - [API security](https://cs.abinantony.io/blog/category/api-security): These posts cover API security testing and design: authorisation enforced per object rather than per screen, token lifetime and revocation, mass assignment, rate limiting on the endpoints that matter, and keeping an inventory of what is actually routable. - [Web security](https://cs.abinantony.io/blog/category/web-security): These posts cover web application security as it turns up in manual testing: broken access control, session and password-reset handling, injection in its less obvious forms, and business-logic abuse that no automated scan will ever report. - [Cloud security](https://cs.abinantony.io/blog/category/cloud-security): These posts cover cloud security the way incidents actually happen: a leaked long-lived key, a build role that can assume anything, storage exposed by a policy nobody re-read, and metadata endpoints reachable from a vulnerable application. - [Secure coding](https://cs.abinantony.io/blog/category/secure-coding): These posts cover secure development practice: fixing vulnerability classes at the framework level instead of one endpoint at a time, keeping secrets out of git, and wiring security checks into CI so the same finding does not return next quarter. - [Compliance](https://cs.abinantony.io/blog/category/compliance): These posts cover the compliance side of application security for Indian product teams: DPDP Act obligations, SOC 2 and ISO 27001 preparation, CERT-In expectations, and how to answer an enterprise security questionnaire honestly without losing the deal. - [Practice](https://cs.abinantony.io/blog/category/practice): These posts cover how to buy and run security work: what to spend at each funding stage, choosing between a penetration test and a code review when the budget only covers one, and running a threat-modelling session that produces tickets instead of diagrams nobody opens. ## Service areas - [Kochi, Kerala](https://cs.abinantony.io/cybersecurity-services/kochi): Penetration testing in Kochi is available on-site across Ernakulam, including Infopark and Kakkanad, or remotely. Engagements cover mobile apps, web applications, APIs and cloud accounts, follow OWASP MASVS and ASVS, and are delivered with a fixed price, a developer-focused report and a free retest. - [Thiruvananthapuram, Kerala](https://cs.abinantony.io/cybersecurity-services/thiruvananthapuram): Penetration testing services in Thiruvananthapuram cover mobile, web, API and cloud assessments for Technopark product teams and government-adjacent projects. Engagements are delivered remotely or on-site from Kochi, follow OWASP standards, and include a free retest of every fixed finding. - [Kozhikode, Kerala](https://cs.abinantony.io/cybersecurity-services/kozhikode): VAPT services in Kozhikode cover vulnerability assessment and penetration testing for web applications, mobile apps and APIs. Delivery is remote-first with on-site options, priced per engagement rather than per day, and every report includes reproduction steps and a free retest after fixes ship. - [Bengaluru, Karnataka](https://cs.abinantony.io/cybersecurity-services/bengaluru): Penetration testing for Bengaluru companies is delivered remotely with the same scope, tooling and reporting used on-site. Engagements target SaaS platforms, fintech products and mobile apps, and produce SOC 2 and enterprise-questionnaire ready reports including an attestation letter and a free retest. - [Chennai, Tamil Nadu](https://cs.abinantony.io/cybersecurity-services/chennai): Application security testing for Chennai organisations covers web, mobile, API and cloud environments, delivered remotely with fixed scope and pricing. Reports map findings to OWASP ASVS and CWE, include remediation guidance for your stack, and come with a free retest once fixes are deployed. - [Dubai, Dubai](https://cs.abinantony.io/cybersecurity-services/dubai-uae): Penetration testing for Dubai and UAE businesses is delivered remotely from India, with a working day that overlaps Gulf hours almost entirely. Assessments cover mobile, web, API and cloud environments and produce documentation suitable for UAE Information Assurance and PDPL-driven vendor reviews. ## Reference - [Pricing](https://cs.abinantony.io/pricing): indicative bands and engagement models. - [FAQ](https://cs.abinantony.io/faq): scoping, delivery, reporting and data handling. - [Glossary](https://cs.abinantony.io/glossary): definitions of the security terms used here. - [Case studies](https://cs.abinantony.io/case-studies): anonymised engagement write-ups. - [Contact](https://cs.abinantony.io/contact): request a scope and a fixed quote. ## Usage This content may be quoted with attribution to Abin Antony Security and a link to the source page. Pricing figures are indicative and dated; check the page's `updated` field before quoting a number.