The cortex-m which is used in the STM32 products, has an SWD (single wire debug, which is really two signals clock and a bidirectional data), think JTAG but fewer signals and different protocol at the pins. It provides the same functionality as a JTAG interface to an on chip debugger, stop the processor take over the bus(es) and look at things so you could most definitely come in through SWD and look at the contents of the flash as well as ram or muck with peripherals, whatever the processor can do you can do.
St provides a usb to SWD debug design called st-link where they have defined the usb interface to this debugger, it is present on most/all of their eval boards which you can remove jumpers and use those front ends on other chips (even of other brands) or break off the debugger and use it as a generic stlink. often cheaper to buy one of the NUCLEO boards and break off or just use the stlink than to buy a dedicated stlink debugger module/dongle. You can use st software or open source software including openocd to talk to the target chip through an stlink debugger.
You are not limited in any way to st-link the chips have the SWD pins exposed (as gpios but so far all the ones I have tried default in a way that you can come in swd) so anything that you can find that supports SWD should work. This includes the myriad of usb to SWD supporting devices including j-link and many others as well as FTDI break out boards for FTDI devices with mpsse. (ft2232 modules, ft4232 modules, etc). Whatever you use needs to be voltage matched or needs to have a sense line (link the stlink and j-link and other generic jtag-like modules) and ideally isolated so that you dont harm the target and that you can sense the targets output in case it is for example a 1.8v part and not a 5.0 or 3.3v. this is very typical normally you power your target device, the debugger connects both swd signals as well as ground for a reference and a sense line to your voltage rail assuming you have one, if you have multiple (unlikely for mcus, other than the analog reference which is not what I am talking about) the one related to the SWD I/O. And then you have to have software that knows how to speak SWD through your debugger (openocd is a very good choice, esp for arm targets, and the price is right and you get way more than you pay for).