<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Crossfyre Blog</title>
	<link>https://crossfyre.io/publications/blog</link>
	<atom:link href="https://crossfyre.io/publications/blog/rss.xml" rel="self" type="application/rss+xml" />
	<description>Distributed recon, offensive-security methodology, and Crossfyre product notes.</description>
	<language>en-us</language>
	<item>
		<title>Rate limits are about where you are, not how fast</title>
		<link>https://crossfyre.io/publications/blog/rate-limits-are-about-where-you-are</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/rate-limits-are-about-where-you-are</guid>
		<pubDate>Fri, 11 Sep 2026 00:00:00 GMT</pubDate>
		<category>Methodology</category>
		<description>Content discovery, subdomain brute force and port scanning all fail the same way, and it is not speed. Here is what actually gets a large authorized scan finished, and the part of it we cannot do for you.</description>
	</item>
	<item>
		<title>Flutter doesn't care what Android trusts</title>
		<link>https://crossfyre.io/publications/blog/finding-flutters-certificate-verifier</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/finding-flutters-certificate-verifier</guid>
		<pubDate>Fri, 11 Sep 2026 00:00:00 GMT</pubDate>
		<category>Methodology</category>
		<description>Every interception tool works by editing one Android config file. Flutter has never read that file. Here is how we find the function that actually decides, without a byte signature, and what happened when we ran it against every Flutter app on one phone.</description>
	</item>
	<item>
		<title>Every false positive we have shipped had the same cause</title>
		<link>https://crossfyre.io/publications/blog/five-rules-that-killed-our-false-positives</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/five-rules-that-killed-our-false-positives</guid>
		<pubDate>Wed, 09 Sep 2026 00:00:00 GMT</pubDate>
		<category>Methodology</category>
		<description>Four separate false positives, four different vulnerability classes, one root cause: the scanner accepted something it had caused as proof. A template matched a marker it had put in the request. An SSRF probe counted a callback our own client made. Here are the four, and the five rules that now stop them, each enforced by a test rather than by review.</description>
	</item>
	<item>
		<title>Five of our authorization tests were passing for the wrong reason</title>
		<link>https://crossfyre.io/publications/blog/tests-that-pass-without-testing-anything</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/tests-that-pass-without-testing-anything</guid>
		<pubDate>Thu, 27 Aug 2026 00:00:00 GMT</pubDate>
		<category>Methodology</category>
		<description>A negative test asserts that a request is refused. Ours were refused, they went green, and five of them never reached the authorization check at all: the request body was malformed, so the server rejected the shape and returned before any permission was evaluated. A passing suite cannot tell that apart from a real refusal. Here is the audit that can.</description>
	</item>
	<item>
		<title>Intercept a pinned mobile app from an unrooted phone</title>
		<link>https://crossfyre.io/publications/blog/mobile-tracer</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/mobile-tracer</guid>
		<pubDate>Wed, 26 Aug 2026 00:00:00 GMT</pubDate>
		<category>Capabilities</category>
		<description>On-device traffic capture is common and it all stops at certificate pinning. The Crossfyre Tracer answers pinning with a server-assisted APK repackage that needs no root and no computer, so a pinned Android app on a stock physical handset yields full request and response bodies. Here is exactly how it works, and what it is not.</description>
	</item>
	<item>
		<title>A scanner that stops at the login page is testing a different app</title>
		<link>https://crossfyre.io/publications/blog/authenticated-scanning-oauth-sso</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/authenticated-scanning-oauth-sso</guid>
		<pubDate>Fri, 21 Aug 2026 00:00:00 GMT</pubDate>
		<category>Guides</category>
		<description>Almost everything worth testing lives behind a login, and an unauthenticated scan never sees any of it. Here is what it takes to get in, and how we handle your credentials without spreading them across a fleet.</description>
	</item>
	<item>
		<title>The bug class scanners cannot see: BOLA, BFLA and BOPLA</title>
		<link>https://crossfyre.io/publications/blog/api-authorization-testing-bola-bfla-bopla</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/api-authorization-testing-bola-bfla-bopla</guid>
		<pubDate>Fri, 21 Aug 2026 00:00:00 GMT</pubDate>
		<category>Methodology</category>
		<description>Broken authorization sits at the top of the OWASP API list and template scanners are hopeless at it, because a valid request from the wrong person has nothing malformed to match on. Here is the testing model that does work.</description>
	</item>
	<item>
		<title>Whose IP address is your scanner using?</title>
		<link>https://crossfyre.io/publications/blog/scans-should-leave-from-your-ip</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/scans-should-leave-from-your-ip</guid>
		<pubDate>Sat, 08 Aug 2026 00:00:00 GMT</pubDate>
		<category>Capabilities</category>
		<description>If a hosted scanner sends probes from its own infrastructure, then every customer shares one reputation, and the first person to get that address blocked breaks the product for everyone else. We audited our own platform against that rule and found a component breaking it. This is the rule, the audit, and what we changed.</description>
	</item>
	<item>
		<title>How Crossfyre scans survive a crashed node</title>
		<link>https://crossfyre.io/publications/blog/crash-safe-recon</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/crash-safe-recon</guid>
		<pubDate>Fri, 12 Jun 2026 00:00:00 GMT</pubDate>
		<category>Capabilities</category>
		<description>A reclaimed instance, a closed laptop lid, a target that starts tarpitting. Most tooling loses the whole run to any of those. Here is what we do instead, and why a dead machine costs you nothing.</description>
	</item>
	<item>
		<title>Valkyrie: turning the scanner firehose into ranked findings</title>
		<link>https://crossfyre.io/publications/blog/valkyrie-triage</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/valkyrie-triage</guid>
		<pubDate>Thu, 11 Jun 2026 00:00:00 GMT</pubDate>
		<category>Capabilities</category>
		<description>Raw recon output is a firehose of mostly noise. Valkyrie is the triage layer that reads it, ranks what matters by severity, and tells you why each finding is worth your time. Here is what it does, what it costs, and what it does not do yet.</description>
	</item>
	<item>
		<title>Scanning is not metered. Credits are only for AI.</title>
		<link>https://crossfyre.io/publications/blog/how-credits-work</link>
		<guid isPermaLink="false">https://crossfyre.io/blog/how-credits-work</guid>
		<pubDate>Wed, 27 May 2026 00:00:00 GMT</pubDate>
		<category>Guides</category>
		<description>Your plan sets your limits and unlocks capabilities. Scanning inside them is not metered, so no per-scan fee and no billed minutes. Credits are a separate wallet, and Valkyrie is the only thing that spends them.</description>
	</item>
</channel>
</rss>