Става въпрос за web. Там нещата са ми мътни обаче разговаряйки в голям брой ITта с огромните заплати ми се видя че на тях нещата са им още по-мътни
Та имам някои въпроси и ще се радвам ако някой внесе някаква светлина

1. Имам страница - написана на прост PHP. Тя приема post request (който е AES кодирано съобщение) и според съдържанието записва дадена променлива в база данни или връща тази променлива в отговора
Въпроса е - как да се защитя от спам постове - те могат да дойдат от различни места - устройство, PC приложение и т.н. Т.е. как да разбера кой точно ми изпраща requesta и аз да отговарям само на него?

2. Съответно по точка 1 към тази PHP страница има вързано едно устройство - съобщенията между тях са AES кодирани. Обаче може да има такива с еднакъв текс - как мога да направя нещо като KeyLOQ така че да ги сдвоявам и да знам че точно устройството и страницата комуникират?

По точка едно ти трябва някаква аутентикация т.е. потребител с парола.
По точка две не се разбира какво искаш да кажеш.

Тази парола нали се подава пак в пост заявката. Дори и кодирана мд5 тя се вижда от трето лице. После той от друго място може да подава пост заявката

Към данните ти се праща и подпис. Подписа се прави с ключ който само у-вото и сървъра знаят. Към данните може да се добави TTL за да се предотврати реплайване на същото съобщение. В данните може да се сложи и уникалният идентификатор на у-вото.
PHP-то ти верифицира подписа и ако всичко е наред - обработва данните.
Тази "далавера" я има като стандарт - JWT.
Всичко с невалиден подпис или таймаутнало - се дропва.

Подписа е повтаряем като паролата и юзера. Така пак могат трети лица да спамят постове. Идеята е да не се повтарят съобщенията. Таймаута изглежда вариант но трябва да слагам и сверявам часовник в устройството а то няма бутон и дисплей трябва да е през някакъв уеб което не ми допада

Краткият отговор е - не можеш! Щом си в публична мрежа, винаги ще получаваш нежелани опити. Въпросът е къде и как ще ги отсяваш.
Вариантите са безброй, само като идеи:
1) Firewall преди сървъра (ако имаш контрол върху него). Още на ниво tcp/ip блокираш досадниците.
2) Ако устройствата поддържат TLS (демек HTTPs) може да настроиш сървъра да иска аутентикация чрез сертификат. Това се прави още преди вдигане на връзката, демек тия, чиито сертификати не те кефят изобщо няма да стигнат до post.
3) В PHP получаваш цялата заявка, отделно имаш информация от къде идва тази заявка, информация за твоя сървър и т.н. От тук нататък има хиляди начини как да решиш дали да я обработваш или направо да я игнорираш. Няма да изброявам стандартните щото са много. Но има и нестандартни, примерно нещо дето ми направи впечатление на един сървър - следи първо дали си посетил една страница и само тогава те пуска на друга страница. Това си беше защита да работи само с клиенти, които ходят на сайта и цъкат линковете. Ако си бот и не те интересува самия сайт като сайт, нормално би подал заявка която да ти върни данни... Е не минава, ако нямаш "правилното" history



За устройства обикновено си слагам допълнителни полета в http хедъра на заявката. Ако щеш марка, модел, сериен номер и т.н. Да не се мъчи сървърът да гадае.
Относно подслушването, принципно за тая цел е https-a. Няма как да се подслушва. Което не значи, че не може да се хаква. В случая устройството е тънката част, т.е. ако някой може да му набие фалшив адрес или по друг начин да се представи като сървър, то той ще получи заявката в явен вид.
За тая цел най-добре ауторизации с подписи или нещо от сорта.

Затова се слага нещо уникално и вече подписа е уникален. Най-лесно е с текуща дата.. По датата си гарантираш уникалност и в същото време валидност на данните.
Това успешно е прилагано в големи проекти с много голямо натоварване и не е имало проблеми.

Относно часовника и уеб интерфейса - има си NTP сървъри - вземай си актуална дата от там. Не ти трябва потребителски интерфейс. Ако щеш - сложи си още 1 PHP файл и върщай текущата дата..

За да се избегнат съобщения с еднакъв текст, слагаш IV - AES го поддържа. Обикновено се генерира различно случайно IV за всяко съобщение и се лепи на края на криптирания текст. Така винаги съобщенията са различни. Подписа вече може да се генерира само на базата на checksum на съобщението и ще е гарантирано различен всеки път. Вече от страна на PHP скрита може да си измислиш валидация - дали само подписа да се проверява, source IP и т.н. - ти ще си решиш. Може да се направи и ограничение по maximum request size за избягване на DoS атаки и прочие. Понеже AES е блок шифър, размерът на криптираното съобщение и залепените за него IV и подпис ще бъдат еднакви, т.е. можеш да кажеш - дай ми последните 16 байта (примерно подписа) и ги валидирай като подпис.

Мисля, че за целта се ползва Anti-Forgery Token

Това е цялата идеология за REST - заявката да е такава, че сървърът да може да я обслужи без да трябва да помни стейт на клиента, т.е. клиента трябва да си прати всичко нужно, за да се обслужи заявката. Демек, stateless архитектура.

Няма проблем с архитектурите...
Нормално имаш веб сървър, който си е самостоятелен и приема както заявки за back-end (от устройства) така и заявки за front-end. Системата и/или системите, които обработват самите заявки са отделно и башка. Често обработката изисква сериализация на заявките или пък имаш атомични операции по базите, демек обработката е сравнително бавен и сложен процес. Поради тая причина е и доста уязвима част, особено откъм DoS атаки.
Затова веб-а често е и защита и контролира колко и какви заявки до кой сървис да се подават за обработка. За тая цел и http хедъра позволява да си добавяш (и ако имаш нужда) и допълнителна информация. Тя е предназначена за веб сървъра, за да може той да реши какво да прави със заявката без изобщо да гледа самата заявка. Не е работа на веб частта да валидира xml-и или да парсва json-и и т.н.
А пък вече същинската обработка на заявката дали ще е stateless или не - това си е нейн проблем. Това няма нищо общо с транспорта до нея.

Не те разбрах - каква е причината да не пращаш весията на софтуера, типа на хардуера, сериини номера и т.н. в заявката?
Аз говорех по-общо за идеологията - това че през хттп можеш да прекараш всякакви идеологии е ясно, визирах че има идея за думата REST и в нея си има основание.
Бавните обработки в бекенда не са проблем, или по-точно, не трябва да се превръщат в грижа на отдалеченото устройство - стреля и забравя, няма време да чака в активен режим някоя база да си мине миграцията и да ми вика "чакай, чакай...". Но за да стане това концепцията/архитектурата трябва да е предвидена. И там е дизайн на по-високо ниво. Да, отдолу ще си е TCP, няма спор.
Схемата на базата тотално не трябва да е зависимост за ембедед фирмуера на отдалеченото устройство- то си мята касовата бележка и не се занимава че на някой му е скимнало да смени в коя таблица ще си пише ДДС-то.

В http заявката имаш хедър и боди. Може и аз да не съм се изразил добре, но под "заявка" се разбира боди-то.
Под "сървър" на практика имаш два сървъра - някакъв веб сървър (примерно апачи) и някакъв бакенд сървър, който си го пишеш ти и прави твоите обработки. При касовите бележки е малко по-сложно, там сървърите и за веб-а и за приложението са повечко или поне са на повечко машини, заради редунданси, лоад балансинг и ала-бала.
Но идеята е, че имаш стандартен веб на входа и къстъм обработки. Като веб-а ти е интерфейс към света, а къстъмът ти е скрит някъде в локална мрежа и до него достига само това, което веб сървъра пропусне. Стандартно заявките (бодитата) се обработват от къстъм сървъра/система и обикновено това изисква време, боди-то трябва да се декодира/валидира, после трябва се рови из бази данни и там операциите трябва да се синхронизират и т.н. Съответно къстъм частта лесно се събаря, особено от хакери. По тая причина обикновено веб сървъра има грижата да отсява каквото може. Но без самия той да отваря и анализира заявки. За да направи това обаче се ползват стандартни неща, като ip-адреси, евентуални стандатни за веб-а неща като кукита, като сесии или друга информация, налична в хедъра на http заявката. Именно тук в (хедъра) е допустимо да се слагат и нестандартни полета от сорта на тип на устройство, сериен номер или каквото е нужно, но нужно на веб сървъра, за да реши дали да пусне заявката към вътрешната мрежа или да я отреже. Това няма никаква връзка с REST, нито по същество с обработки и т.н.
Това ти е просто едно защитно ниво на входа и е по-скоро транспортно ниво, отколкото приложно ниво. И няма проблем да е свързано с фърмуера или с каквото е нужно. Примерно говориш за касови бележки... ами сървъра на НАП следи от коя SIM карта идва заявката и за кое устройство се отнася. Ако двете не пасват, заявката се отсява и изобщо не се обработва. Сега това е доста краен пример, не казвам че трябва да се правят чак такива изгъзици, но е факт че могат да се правят

Да, явно говориш за защита от нежелани заявки. Аз говорех за функционалната част, която също има нужда от такива данни - например за да разбере дали има нов фирмуер трябва да получи типа на устройството и текущия фирмуер.
А предполагам че още в джуниър нивото учат хакерчетата да копират заявката от реалното устройство и на нейна база да магарят разни дивотии.

Ако няма да се ползва някой от многото стандарти в този див-див интернет (като https, jwt), може да се измисли една проста схемичка:

- устройството, освен съобщението, криптира (със същия или друг таен ключ) и идентификатор, който може да е сериен номер или друго, НО към него залепва и някакъв (pseudo) random. Тоест: AES (ID + random) и това нещо се слага в header на POST заявката.
- сървъра декриптира този token и проверява идентификатора, ако всичко е наред декриптира съобщението.

Възможният път за атака е хакерче с крипто-ферма.

По-важното обаче къде и как се блокират нежеланите гости.
Както е написано по-горе, най-добре още на ниво защитна стена по IP адрес ако е приложимо.

След това на ниво web сървър зависи от сървъра.
Ако е споделен хостинг, възможностите да се спре заявката преди целия POST са никакви.

На VPS или собствен сървър с разни магии в конфигурациите на Apache/Nginx е възможно.

Но, по-добре е да си напишеш мини сървър с node.js или PHP, което е по-лесно отколкото звучи.
Така можеш да блокираш заявката ако не ти хареса нещо в реда:


Но като ще е така, защо да не са сурови данни директно по TCP socket.